[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [dsdp-tm-dev] RE: SubSystemConfiguration vs. SubSystemFactory ??
|
Yes, the IConnectorService is different, you are
right.
I could imagine that the Configuration (be it extension
point or programmatically)
provides
1.) Generic Properties (icon, name,
vendor, category)
2.)
ISubSystemFactory
3.) IConnectorService
4.) List of IService
5.) Properties to configure the
rest
This should be enough to do all the "plumbing"
needed.
No, I'd like to keep the number of extension points to an
absolute minimum.
Either just one for the Configuration, or two (one for an
UI-less implementation
and another one for the UI on top of
it).
I think the type of service could be decided in the actual
SubSystemFactory,
that needs to be designed to work with the various types of
service anyway.
It can use "instanceof" to decide which service is which.
The extension point
and the configuration, however, could just transparently
work with IService
since they do not need to know what which one
means.
Cheers,
--
Martin Oberhuber
Target Management Project
Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
3) IConnectorService doesn't
implemnet IService but it's really a different beast.
When contributing services via the extension point
would tehy be contributed generically, such that programmatically, we'd have
to decide what each means (i.e. IFileService vs ISearchService)..or would we
start having to create new extension points for each type of subsystem
configuration (i..e one for files, one for shells, etc)?
____________________________________
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 11:26 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
?? |
|
3) Yes.
All Services implement IService, right?
So there could be an IServiceFactory
interface, implemented by
e.g. IFileService, ISearchService, IRemoteCmdService,
IShellService.
The extension point could support a list of
services to be contributed
to the configuration. The SubSystemFactory (or the
configuration?)
would be responsible for receiving all configured factories, filtering
out those that are
supported (through instanceof), casting them to
the proper interfaces and installing
them.
The advantage of an ISubSystemConfiguration class, as opposed to
doing everyting by extension
point, would be that default configurations
can be re-used more easily... the extension point would need
to list
all services for each
and every configuration again.
Hmm.... perhaps we'll end up with separate
extension points for the
factory
and for the configuration eventually, with the configuration being
totally UI-Less and the factory UI
dependent?
Cheers,
--
Martin Oberhuber
Target Management Project
Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
From: David McKnight
[mailto:dmcknigh@xxxxxxxxxx]
Sent: Friday, August 11, 2006 4:43
PM
To: Oberhuber, Martin
Cc: Target Management developer
discussions
Subject: RE: [dsdp-tm-dev] RE: SubSystemConfiguration
vs. SubSystemFactory ??
Hi Martin,
2) Okay, just means we'll need a few different
types of factories
3) So this extension point would provide the means of specifying
each of the factories involved? We'd need to make it flexible enough to
configuration additonal serivce factories, depending on the factory type -
like the ISearchServiceFActory.
____________________________________
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 10:25 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,
2) The point is that if you have a Configuration create something,
you
blow up the class, especially if you really want to just
re-use an
existing factory. It's better to delegate to what
you already have.
3) Yes, I'm suggesting a single extension point just for
the configuration,
implying everything that needs to be
configured.
Cheers,
--
Martin Oberhuber
Target Management Project
Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
From: David McKnight
[mailto:dmcknigh@xxxxxxxxxx]
Sent: Friday, August 11, 2006 4:22
PM
To: Oberhuber, Martin
Cc: Target Management developer
discussions
Subject: RE: [dsdp-tm-dev] RE: SubSystemConfiguration
vs. SubSystemFactory ??
Hi Martin,
By the adapters, I don't mean the view adapters, I mean the
thing that takes a subsystem-independent IHostFile and wrappers it to make it
a subsystem-dependent IRemoteFile.
1) In RSE 7, there never was a service, service
adapter and all that replaceable stuff so the concepts have changed
slightly
2) Does a
subsystem configuration really need to delegate - wouldn't it know exactly
what it needs to create? I mean, I don't see the need for factories to
be contributions to a configuration.
3) For this case are you suggesting no extension
point for the factory - just for the configuration, implying 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 09:58 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
absolutely agree: There needs to be one place that holds all these
factories
together. Note that currently, these are _not_ all in one place
since the
RemoteElementAdapters are typically registered by the activator,
and not
by
the configuration.
The place that's holding all things together could be
1.) The
ISubSystemFactory class.
That's how it has been in RSE 7, the class
has been renamed to ISubSystemConfiguration.
I don't like the plain renaming
because it's misleading.
2.) An ISubSystemConfiguration class.
But then,
the configuration should not take on duties of the factory (by deriving
from
the factory), but it should delegate to the various factories where
needed. That's
in-line with the common best practice that
"composition" of classes is usually better
than "extending" classes in
order to add functionality.
3.) The subSystemConfiguration extension
point.
This would allow for plain "reconfiguration" of
existing services, by naming existing
factories where needed. Compared
to (2), it's basically the same pattern but moving
from a programmatic
approach to a data-driven approach. This might eventually
be
helpful if we want to support headless (UI-less) operation by instanciating
only
service classes instead of the full-blown UI-dependent classes from a
headless
application.
I'm most inclined towards (3), and I see the
path towards it gradual: Leave everything
in the factory for now (because this _is_ how
things still work), and split out the
various tasks into separate
factories or a configuration class gradually.
Thanks for your thoughts and
discussion!
I consider this really exciting and helpful.
Thanks,
--
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: Friday, August 11, 2006 3:16 PM
To:
Oberhuber, Martin
Cc: Target Management developer
discussions
Subject: 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