This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 149126 - Need for arch and ui changes in remote hosts database
Summary: Need for arch and ui changes in remote hosts database
Status: NEW
Alias: None
Product: cnd
Classification: Unclassified
Component: Remote (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Vladimir Kvashin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-03 20:48 UTC by ivan
Modified: 2010-05-26 13:40 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ivan 2008-10-03 20:48:49 UTC
Currently the remote hosts database in CND is only accessible and tightly
intertwined with the cnd compilerset database (see #147543).

In the process of working with an analogous DB in dbxtool and getting dbxgui
to do remote development the following became clear to me:

- The hosts database should not be CND-specific and needs to be pulled
  up and out and provided as a general service.
  This would help for example the dtrace module to not have to do it's
  own remote host DB.

- It is a collection of resources and as such probably the best primary
  place for accessing it would be where all other lists of things get
  accessed from, the Tools menu (See #149122).

- In addition the Hosts DB should be accessible and editable from a variety of
  places, like a [...] button next to the host combo-box in an attach dialog.

- The set of resources associated with a host at the moment is fixed (at least
  according to the UI) it is path mappings and compilersets. This needs to be
  generalized so an arbitrary module/feature can hang it's own feature-specific
  set of resources on a Host object. 

      In general most remote resources are file paths but they can also
      be other things like port #'s.

      Sometimes these resources are discoverable, but sometimes the user has to
      specify them. The current CND compilerset had initially focussed too
      much on discovery with very little provision for overriding.

  This could be an interface, ResourceSet, and PathMap and CompilerSet would become implementors of this interface. 
  A ResourceSet could have some additional methods like discover(), revalidate etc.
  ResourceSet would be an analog of ConfAuxObject (and better named :-)

  Some use cases:
  - The dtrace module has it's own remote server and would probably like to
    discover and remember the install location of each server per remote
    host. 

  - I understand that CND has a "get this resource there" feature. A ResourceSet is a
    natural place for managing this and remembering where "it got to" per host.

  - SunStudio has it's own remote services (a misc collection of stuff) which has nothing
    to do with compilersets (we're just lucky that if a SunStudio compiler is found that
    this other stuff can be found as well, but that isn't the general case).