[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-tm-dev] RE: SubSystemConfiguration vs. SubSystemFactory ??
|
Hi Martin,
So do you think we'd need an IServiceFactory
for the configuration? If we start down that path, then we also need
IConnectorServiceFactory, and then depending on the underlying model, we'd
need something to create service model to subsystem model adapters, such
as IHostFileToRemoteFileAdapter,
which converts IHostFile to IRemoteFile. The other thing is that
some subsystems have additional services, such as the ISearchService for
files - would that just be created from the IServiceFactory? For
each of these factories, we'd still need one object to hold them altogether
so that there's a clean switch when you change from one configuration to
another for a given subsystem. The concept of service didn't exist
when the documentation was written, so I'm not sure it buys us that much
there if we role up the configuration into the factory.
____________________________________
David McKnight
Phone: 905-413-3902 , T/L: 969-3902
Internet: dmcknigh@xxxxxxxxxx
Mail: D1/140/8200/TOR
____________________________________
| "Oberhuber, Martin"
<Martin.Oberhuber@xxxxxxxxxxxxx>
11/08/2006 08:52 AM
|
|
To
| David McKnight/Toronto/IBM@IBMCA
|
|
cc
| "Target Management developer discussions"
<dsdp-tm-dev@xxxxxxxxxxx>
|
|
Subject
| RE: [dsdp-tm-dev] RE: SubSystemConfiguration
vs. SubSystemFactory ?? |
|
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?
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 Martin Oberhuber
Sent: Thursday, August 10, 2006 10:19 PM
To: David McKnight
Cc: Target Management developer discussions
Subject: Re: [dsdp-tm-dev] RE: SubSystemConfiguration vs. SubSystemFactory
??
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
