Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dsdp-tm-dev] RE: SubSystemConfiguration vs. SubSystemFactory ??

Hi Dave,
I'm afraid I cannot follow you thoroughly.
I didn't think about contributing the configuration and the factory separately, but
only provide an extension point for the factory. The factory would be responsible
for creating the subsystem, and its initial configuration. I wouldn't see what the
advantage of separate contributions for configuration and factory would be.
We probably shouldn't deviate from what we currently have too much right now.
Currently, we have a static configuration that is tied 1:1 to the factory. With my
proposed change, the factory could provide configurations that are not so much
tied to it any more, and thus more flexible.
I didn't think about persisting modified configurations though, so allowing
configurations to change at runtime is probably something to consider for
2.0 (and keeping them static for now).
Perhaps an example could help:
class SshSubSystemFactory implements ISubSystemFactory {
   public ISubSystem createSubSystemInternal() {
       return new SshSubSystem( getDefaultConfiguration(), ... );
   public ISubSystemConfiguration getDefaultConfiguration {
       //the configuration can be an anonymous inner class,
       //or a real class defined outside
       return new DefaultSubSystemConfiguration {
           // define overriders here
           public boolean isCaseSensitive() { return true; }
Or, if we want to keep code closer to what it is right now:
class SshSubSystemFactory implements ISubSystemFactory, ISubSystemConfiguration {
   public ISubSystem createSubSystemInternal() {
       return new SshSubSystem( this, ... );
   public boolean isCaseSensitive() { return true; }
In both cases, the Subsystem can replace its current configuration with
something different later on.
Another option, for DStore for instance, would be to have
class DStoreWindowsSubSystemConfiguration extends DefaultSubSystemConfiguration {
   public boolean isCaseSensitive() { return true; }
class DStoreUnixSubSystemConfiguration extends DefaultSubSystemConfiguration {
   public boolean isCaseSensitive() { return false; }


Martin Oberhuber
Target Management Project Lead, DSDP PMC Member


From: dsdp-tm-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of David McKnight
Sent: Thursday, August 10, 2006 5:01 PM
To: David Dykstal
Cc: Oberhuber, Martin; Target Management developer discussions
Subject: [dsdp-tm-dev] RE: SubSystemConfiguration vs. SubSystemFactory ??

I like the idea but I'm thinking that it would be good to still keep the service creation with the configuration rather than the factory.  There could be a single factory for each different type of service subsystem:

        FileServiceSubSystemFactory  --> produces --> FileServiceSubSystem
        ShellServiceSubSystemFactory --> produces --> ShellServiceSubSystem
        ProcessServiceSubSystemFactory --> produces --> ProcessServiceSubSystem

The factory would be responsible for the lifecycle of the subsystem but would use the configuration to define, not only the attributes in terms of "isCaseSensitive()" and such but also the services themselves.   The factory could use the the current to setup the service configuration for a subsystem.  For each, service there could be a different configuration:


A given factory may use one of the available configurations for creating the subsystem as well as changing it's configuration - for example, when switching between FTP and DStore.

If we were to take this approach, we could keep the configuration extension point pretty much the same - since it's really there to contribute the services, but we'd need to introduce a new extension point for the subsystem factory.  So there would be a FileServiceSubSystemFactory contribution before any service configurations are defined.

What do you think of this?

David McKnight    
Phone:   905-413-3902 , T/L:  969-3902
Internet: dmcknigh@xxxxxxxxxx
Mail:       D1/140/8200/TOR

David Dykstal/Rochester/IBM@IBMUS

10/08/2006 10:13 AM

"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
"David McKnight" <dmcknigh@xxxxxxxxxx>, "Target Management developer discussions" <dsdp-tm-dev@xxxxxxxxxxx>, "Kushal Munir" <kmunir@xxxxxxxxxx>
RE: SubSystemConfiguration vs. SubSystemFactory ??Link

Interesting idea.

In most cases where we have to grab the SubSystemConfiguration from the subsystem we would continue to do so.  So its possible this won't be as bad as I initially suspected. This is a pretty pervasive hit though and it affects the extension points. Would you expect to define both subystem factory and subsystem configuration extension points independently or would a subsystem factory provide a subsystem configuration to the subsystems it creates?
David Dykstal

Back to the top