Hi Dave,
I thought about your suggestion
again.
We'll probably need a bit more time to sort out the
actual details of separating
ISubSystemConfiguration from ISubSystemFactory. What's
important for me,
though, is that whenever a class is responsible
for creating something, I'd like
to name it
"...Factory".
Bringing back the name ISubSystemFactory instead of
ISubSystemConfiguration,
for what essentially _is_ a factory, has the very big
advantage that all documentation
referring to ...factories would be correct again. And
that's a lot!!
For me it looks like even if a user re-uses an existing
FileServiceSubSystemFactory,
he'd supply his own IFileService. In other words, the
configuration would need to name
a factory for creating IFileService objects,
wouldn't it?
The extension point, finally, names a "type" or
"configuration" of subsystem. Elements
of the extension point (which is a configuration) can
be the ISubSystemFactory class,
the IConnectorService class, and the IServiceFactory
class. Such an extension point
would (I think) make the duplicate code for the current
factories eventually unnecessary,
and all the "plumbing" of the configuration would
occur via the extension
point.
The extension point would be the
"configuration" but it would name the factory
classes which are responsible for creating
objects of proper type.
This would also be a little bit in line with what the
Platform does for
extension points
org.eclipse.update.core.featureTypes --> element
<feature-factory>
org.eclipse.update.core.siteTypes --> element
<site-factory>
I suggest we go ahead with renaming classes accordingly
for now. I'll send out
a separate E-mail with requested refactorings. We
can think about the split-up
later on if we want -- it would affect the code much
less than doing all at once,
since it would just be one additional item in the
extension point.
How does that sound?
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
