Community
Participate
Working Groups
The extension point org.eclipse.rse.ui.subsystemConfigurations should contain the standard name for the service as well as the required transport. It is required to allow the RSE service discovery agent to interact with standard discovery servers. Standard service names are listed in the IANA assignement of port numbers (http://www.iana.org/assignments/port-numbers) and in the dns-sd service types list (http://www.dns-sd.org/ServiceTypes.html). The standard name and transport can be used as the "id" field of the extension point as in org.eclipse.examples.daytime (id=daytime.tcp), or they can be added as new attributes.
I think I'd prefer a new slot (e.g. "standardServiceName") instead of re-using the ID. Consider the case where multiple vendors e.g. windriver and symbian provide alternate implementations of a common protocol like telnet -- you'd need different IDs but the same standardServiceName. Javier can you come up with an example of what you think a correct extension point would look like?
This patch would add two new attributes to org.eclipse.rse.ui.subsystemConfigurations We could also provide the possibility to support multiple service names and transports on the same service, by using semicolon separated names. It could be useful if the plugin can understand more than one protocol (for example ftp and tftp). ### Eclipse Workspace Patch 1.0 #P org.eclipse.rse.ui Index: schema/subsystemConfigurations.exsd =================================================================== RCS file: /cvsroot/dsdp/org.eclipse.tm.rse/plugins/org.eclipse.rse.ui/schema/subsystemConfigurations.exsd,v retrieving revision 1.2 diff -u -r1.2 subsystemConfigurations.exsd --- schema/subsystemConfigurations.exsd 27 Oct 2006 02:52:34 -0000 1.2 +++ schema/subsystemConfigurations.exsd 8 Feb 2007 17:30:35 -0000 @@ -189,6 +189,20 @@ </documentation> </annotation> </attribute> + <attribute name="serviceType" type="string"> + <annotation> + <documentation> + + </documentation> + </annotation> + </attribute> + <attribute name="tranport" type="string"> + <annotation> + <documentation> + + </documentation> + </annotation> + </attribute> </complexType> </element>
Sounds good to me, when you add documentation and examples to the patch. So, both attributes would be optional since there may also be vendor-specific subsystems which are not discoverable anyways or do not have any standard protocol. I like the idea of multiple possible protocols in one subsystem. I'm wondering if serviceType + transport could be combined into one field, because if this is not done we'd have problems with the semicolon separated list e.g. serviceType="ftp;tftp" transport="tcp;udp" makes it unclear whether ftp.udp or tftp.tcp are allowed. I'd thus suggest serviceType="_ftp._tcp;_tftp._udp" please give better examples if you can. I, for one, am not sure about the underscores, sometimes I see them, sometimes I don't.
(In reply to comment #3) > Sounds good to me, when you add documentation and examples to the patch. Sure, I just wanted to propose the plugin structure. I'll add documentation and examples before committing the changes. > I'm wondering if serviceType + transport could be combined into one field Yes, also it adds less attributes to the extension point, that can cause confusion. > makes it unclear whether ftp.udp or tftp.tcp are allowed. I'd thus suggest > > serviceType="_ftp._tcp;_tftp._udp" sounds good to me as well. The names with _ are follwing DNS specification, and matches exactly what zeroconf expects, so this syntax sounds good to me.
I'm wondering if the new field in the extension point should somehow indicate by its name already that some standard content is expected. Also, it should indicate that multiple items are allowed. For example, standardServiceTypes="..." dnsServiceTypes="..." dnssdServiceTypes="..." discoveryServiceTypes="..." serviceTypes="..." Another thing I'm wondering is, whether we don't put too much of a specific implementation of service discovery into this. Extenders might want to implement service discovery differently. What if we left the subsystemConfigurations alone, and provided some kind of mapping (by Preferences, or extension point), between subsystemConfiguration id and dns-sd service type?
I would like to keep it as simple as possible. We could only add the standard systemType to the subsystem, and then the transport, that has to be part of the discovery protocol, can be added as a subsystem property (same as the port number).
Created attachment 61299 [details] org.eclipse.rse.ui.subsystemConfigurations modification to contain the service id + updated FTP service I would like to add a new optional attribute, being the standard name of the service that would be expected to be advertised from a service discovery server, independently of the discovery protocol (DNS-SD, SSDP...). The patch also includes the updated FTP plugin. This step is required before the submission of the functional service discovery wizard to correctly match advertised services with their implementation. Should this modification be publicly voted before the submission ?
Created attachment 61863 [details] standard service name and transport proposal Could you check the proposal patch attached ? Applying it to your workspace should allow discovering DNS-SD services and filtering them. The patch also includes the update for FTP to accept FTP-TCP based servers, so you should be able to filter and create in your workspace servers advertised through _ftp._tcp. Dummy servers can be advertised using the Bonjour SDK (http://developer.apple.com/networking/bonjour/download/)
Martin proposed adding only a new attribute such as serviceType="_ftp._tcp;_ftp.udp;" I think it's a good idea, as it provides the service information in only one attribute, though the syntax is quite DNS-SD like
Committed service discovery using DNS syntax like serviceType="_ftp._tcp;_ftp.udp;"
Can you please also add a proper serviceType slot for the subsystemConfigurations for ssh, sftp and daytime, such that we have an example for users.
I'd also like to see it reflected in the extension point documentation, that 1.) service discovery will not be able to discover a subsystem if the slot is not filled. 2.) The slot is really just a standard description of what the subsystem does. As such, it may be used for other things than service discovery. I'm wondering if we should also add a serviceType slot for the dstore based subsystems ("dstore._tcp" -- I assume that any specifiers without a leading underscore can be used freely even if they are not officially IANA registered).
org.eclipse.rse.ui.subsystemConfigurations now contains an optional attribute serviceType containing the service name and the transport for the service ( eg. "_ftp._tcp") allowing matching it with a remote discovered service.
[target cleanup] 2.0 M6 was the original target milestone for this bug
Comment on attachment 61863 [details] standard service name and transport proposal iplog- since Javier became committer in 2006 already: http://dev.eclipse.org/mhonarc/lists/dsdp-tm-dev/msg00375.html
