Hi Dave,
ahh, now I see! Your suggestion sounds excellent.
I guess there's still a few things to sort out, like where does the
ConnectorService come from (would there be
ISubSystemConfiguration.getConnectorService()?
Then, what about methods like supportsFilters() which are more a static
configuration property than a dynamic one and thus be more associated
with the factory, than the actual config -- after all they define
capabilities of the subsystem implementation, and not its actual
configuration.
Finally, the extension point... should the extension point name both
the config and the factory classes?
Or should the config have a method like getSubSystemFactory()?
For me it sounds like the config is "above" the factory, it's like the
master putting all items together.
Cheers,
Martin
David McKnight schrieb:
I'm seeing the value of the
configuration
not so much for things like "isCaseSensitive" but for providing
the actual service implementations. We define the
FileServiceSubSystem
independently of any service implementation. Currently the means
of providing each service implementation is via each the subsystem
configuration
however each is also the thign that creates the subsystem. Each
subsystem configuration does some redundant thing - they each create
FileServiceSubSystem.
RSE does allow you to switch configurations and thus thus services
such that the subsystem configuration that was intially used to create
the subsystem would no longer be used after a subsystem configuration
gets
switched, which is kind of weird. That problem would be solved with
an independent factory.
If no subsystem configurations are
contributed
then there would never been a subsystem to create, so I don't see the
value
of having a default configuration. I guess I'm sort of thinking along
these lines:
class
FileServiceSubSystemFactory
implements ISubSystemFactory {
public ISubSystem
createSubSystemInternal(ISubSystemConfiguration initialConfiguration) {
return
new FileServiceSubSystem( initialConfiguration, ... );
}
}
There would never be an
SshFileServieSubSystem,
nor a DStoreFileServiceSubSystem - there's only FileServiceSubSystem
with
a configuration that provides the service implementation.
class
SshSubSystemConfiguration
implements ISubSystemConfiguration {
public boolean
isCaseSensitive() { return true; }
public IFileService
getFileService(IHost host);
....
}
Does that make any sense?
____________________________________
David McKnight
Phone: 905-413-3902 , T/L: 969-3902
Internet: dmcknigh@xxxxxxxxxx
Mail: D1/140/8200/TOR
____________________________________
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; }
}
Comments?
Cheers,
--
Martin Oberhuber
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
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:
Example:
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:
Example:
DStoreFileServiceConfiguration
SSHFileServiceConfguration
FTPFileServiceConfiguration
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
|
|
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
david_dykstal@xxxxxxxxxx
|
