[
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; }
}
Comments?
Cheers,
--
Martin Oberhuber
Target Management Project
Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
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
|
|
To
| "Oberhuber, Martin"
<Martin.Oberhuber@xxxxxxxxxxxxx>
|
|
cc
| "David McKnight"
<dmcknigh@xxxxxxxxxx>, "Target Management developer
discussions" <dsdp-tm-dev@xxxxxxxxxxx>, "Kushal Munir"
<kmunir@xxxxxxxxxx>
|
|
Subject
| 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
david_dykstal@xxxxxxxxxx
