Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[dsdp-tm-dev] Please comment: SubSystemConfiguration implementations as public API?

Hi all,

while we went forward quickly last week in making subsystem
implementation details "internal", I came across an issue
that we need to solve:

Up to now, we have advertised that people, who want to 
register an _existing, known_ subsystem (e.g. FTP) against 
a new systemType need to create the subsystemConfigurations
extension point, and reference the existing well-known class
there.

Now if all FTP (ssh, local,...) implementations are 
"internal", we cannot recommend this any more. 
There are two possible solutions to this:

1.) Make the SubsystemConfiguration implementations public
    API again. This would be:
       FTPFileSubSystemConfiguration
       SftpFileSubSystemConfiguration
       SshShellSubSystemConfiguration
       ...

2.) Since bug [173265] was fixed, there is now the possibility
    to link up a new systemType with a given list of known
    subsystemConfiguration Ids, by specifying the extension 
    point attribute "subsystemConfigurationIds".
    Doing so, we could keep the classes "internal".


Since I always like to keep the API small, I'm slightly
in favor of (2). The drawback of (2) is, however, that the
subsystems can only be taken _exactly_ as they were defined,
without the slightest modification. With approach (1), the
actual contributor of a subsystem can override some configuration
like 
   isCaseSensitive()

Note that FTP is somewhat special because I see a need 
to allow users contribute their own Commons/Net 
FTPFileEntryParser to custom FTPSubSystemConfigurations
anyways, so we may need to make some of FTP API (but
not ssh, or local).

Please let me know your preference. Do you see any other 
methods on SubSystemConfiguration implementations that 
should potentially be overridden? Or should we go with
(2) for now and solve the issue of improved "configurability"
of existing subsystems in a manner as it is also needed by
improved autodetect (i.e. splitting up static and dynamic
subsystem configuration better)?


Thanks,
--
Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm


Back to the top