[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-tm-dev] RE: SubSystemConfiguration vs. SubSystemFactory ??
|
Martin,
I like what you're proposing, but I do have a question. I might be
misunderstanding this, but let's say I have different services for a system
type which I define using one extension, i.e. I list the services in the
extension I define. If you want to add another service to the same system
type, how would you do it through the Configuration extension point?
Thanks,
Kushal Munir
Websphere Development Studio Client for iSeries
IBM Toronto Lab, 8200 Warden Ave., Markham, ON
Phone: (905) 413-3118 Tie-Line: 969-3118
Email: kmunir@xxxxxxxxxx
"Oberhuber,
Martin"
<Martin.Oberhuber To
@windriver.com> "Target Management developer
Sent by: discussions"
dsdp-tm-dev-bounc <dsdp-tm-dev@xxxxxxxxxxx>
es@xxxxxxxxxxx cc
Subject
08/11/2006 12:21 RE: [dsdp-tm-dev] RE:
PM SubSystemConfiguration vs.
SubSystemFactory ??
Please respond to
Target Management
developer
discussions
<dsdp-tm-dev@ecli
pse.org>
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
From: dsdp-tm-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of David McKnight
Sent: Friday, August 11, 2006 6:15 PM
To: Oberhuber, Martin
Cc: Target Management developer discussions
Subject: RE: [dsdp-tm-dev] RE: SubSystemConfiguration vs. SubSystemFactory
??
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>
To
11/08/2006 11:26 AM 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>
To
11/08/2006 10:25 AM 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>
To
11/08/2006 09:58 AM 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>
To
11/08/2006 08:52 AM 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
____________________________________
"Oberhuber, Martin"
<Martin.Oberhuber@xxxxxxxxxxxxx>
To
10/08/2006 12:44 PM 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'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/Rocheste
r/IBM@IBMUS
To
"Oberhuber, Martin"
10/08/2006 10:13 <Martin.Oberhuber@xxxxxxxxxxxxx>
AM 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
_______________________________________________
dsdp-tm-dev mailing list
dsdp-tm-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
