[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-tm-dev] RE: SubSystemConfiguration vs. SubSystemFactory ??
|
Hi Kushal,
The XML used by extension points supports sequences,
mind the _two_ service tags below:
<extension point="org.eclipse.rse.subSystemConfiguration">
<configuration name="SshFileSubSystem" icon="icons/files.gif">
<factory
class="org.eclipse.rse.subsystems.files.FileServiceSubSystem" />
<connectorService
class="org.eclipse.rse.connectorservice.ssh.SshConnectorService" />
<service
class="org.eclipse.rse.services.ssh.files.SftpFileService" />
<service
class="org.eclipse.rse.services.search.ShellBasedSearch" />
</configuration>
</extension>
Cheers,
--
Martin Oberhuber
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Kushal Munir
> Sent: Friday, August 11, 2006 7:25 PM
> To: Target Management developer discussions
> Cc: Target Management developer discussions;
> dsdp-tm-dev-bounces@xxxxxxxxxxx
> Subject: 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
>
>
> _______________________________________________
> dsdp-tm-dev mailing list
> dsdp-tm-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
>
