[dsdp-tm-dev] RE: SubSystemConfiguration vs. SubSystemFactory ??

["Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>]

Hi again,

thinking again about it, I guess the _right_ thing to do
would be to separate the ISubSystemFactory from the 
ISubSystemConfiguration.

Then, a single factory could be registered, and it could
create subsystems with different configurations. 

For instance, an SSH subsytem factory could decide 
dynamically after connect, whether the connected 
subsystem would be case sensitive or not (Isn't this
a problem currently with dstore whether it's connected
to a windows or linux host??) Or other configuration
features could be determined dynamically based on the
server protocol available e.g. SFTPv1 vs. SFTPv2.

We'd have the factory would handle lifecycle
as well as static properties, and the configuration
would handle more dynamic properties:

interface ISubSystemFactory {
   //lifecycle and any static properties
   create...
   delete...
   rename...
   get{Id,Image,LiveImage,...}
}

interface ISubSystemConfiguration {
   //any dynamic properties
   supports...
   isCaseSensitive()
   isPortEditable()
}

the current java already talks about a similar separation,
since most of the supports... methods are declared like
"true if instances created by this factory..."
The change would also make the tremendously large interface
more easy to understand.

I think the change would probably not be tremendously 
hard to make, if we only split up the interfaces in a 
first step, and allow the abstract base class implement
both interfaces.
In a second step, we could define a DefaultSubSystemConfiguration
which defines the standard properties, and have a method
ISubSystem.getSubSystemConfiguration() that returns the 
default by default, or a custom one if the user overrides
it.

Thoughts?

Cheers,
--
Martin Oberhuber
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm 

> -----Original Message-----
> From: Oberhuber, Martin 
> Sent: Thursday, August 10, 2006 3:19 PM
> To: 'David Dykstal'; 'David McKnight'; 'Kushal Munir'
> Cc: 'Target Management developer discussions'
> Subject: SubSystemConfiguration vs. SubSystemFactory ??
> 
> Hello Dave's and Kushal,
> 
> While I was working on RSE today, I was wondering why you had
> chosen to rename SubSystemFactory --> SubSystemConfiguration.
> 
> After all, it *is* the factory which creates new subsystems,
> isn't it? Sure enough, it also holds configuration data about
> the subsystems, but in terms of lifecycle, the interesting 
> point is that the factory exists before the subsystem -- and
> the configuration data will apply to *all* new subsystems
> created.
> 
> In other words, it is never possible to have different configurations
> for subsystems of the same type, because all of them are created
> by the same factory, right?
> 
> Moreover, there are still lots of Javadoc comments and local
> variable names etc. that refer to factories.
> 
> Looking at existing Platform extension points, I'm finding:
>   org.eclipse.ui.console.consoleFactories
>   org.eclipse.ui.elementFactories
>   org.eclipse.ui.presentationFactories
> The semantics especially of the last one is a bit similar to 
> our subsystem configurations I think. I found only one named
>   org.eclipse.ui.acceleratorConfigurations
> which is deprecated.
> 
> Well it's my personal feeling, but I'm more comfortable with
> a SubSystemFactory than with a SubSystemConfiguration. What
> would you think about renaming it back ??? I don't think it
> would be much work to do, a simple plaintext-search-and-Replace
> of SubSystemConfiguration (case sensitive!) should do since
> the word is long enough to avoid unintended matches. Replacing
> in html, xml etc. as well would also fix ISV docs along the 
> way. I could make the change easily if you agree.
> 
> Comments?
> 
> Thanks,
> --
> Martin Oberhuber
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm