[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[dsdp-tm-dev] RE: Registering discovered services in RSE
|
Hello Javier / Dave,
Discovery on existing connections:
Doing the autodetect process on every "connect" request seems like an overkill
for me. I don't think that it is a very common use-case that a previously
detected (and used) service would suddenly no longer be available. But I could
imagine that when RSE runs into an error during connect, the error dialog could
say e.g. "Error - cannot connect to FTP service - do you want to discover
services again?"
Regarding discovery in the wizard,
I absolutely agree with Dave.
-
A set of subsystems / services is installed in
RSE (grouped by "SystemType").
-
Discovery will help to select which of the
installed services to instanciate for a given connection. This selection
process may need user interaction or not, but it would be assisted by
Disocvery.
With this background, it seems to make sense to
define a SystemType "Discovery"
against which all available subsystems / services are
registered. By creating a new system of type "discovery", the user says "I'm
going to connect to a system for which I know auto-discovery will
work".
In the System creation wizard, discovery will disable those
subsystems / services that are not actually available. In case more than one
service remains for a given subsystem, the user will need to choose which one he
prefers.
Currenty, the subsystem / service selection for system
types is partially static in RSE (through the extension points) and partially
manual (through the wizard). Discovery will help to make this more dynamic. What
it takes in RSE seems to be mostly improvements of the selection mechanisms in
the wizards. Some of these are already covered in
For
some subsystems, their implementor might know that they are not possible to
auto-detect (e.g. some JTAG hardware debuggers). Such subsystems would then not
be registered with the "Discovery" system type but only with their own system
type e.g. "ACME Hardware Debugger Connection".
Cheers,
Martin
--
Martin Oberhuber - WindRiver,
Austria
+43(662)457915-85
Hi Javier,
What you're doing certainly sounds very interesting and
I think it will be very valuable. I'm wondering whether this service
discovery capability should apply to more than just the new connection wizard
- I think it would make sense to make use of this with existing connections
(for cases where a previously used service is no longer available or a new
service has been installed). Subsystems, such as files and shells, may
exist regardless of the service being used - I would think the service
discovery mechanism would help determine the following:
- Which subsystems should be enabled
(and visible). If no service is available for a subsystem, then
there's no sense showing it.
- Which service a given subsystem
should use. If only the ftp service is available for files, then it's
clear which service should be used by the subsystem. Things are a
little more complicated when there are multiple services for a given
subsystem.
When applied to
the wizard, then I could imagine the service discovery tool doing the
following:
- Determining which subsystems
actually have services - and therefore which subsystem pages to present in
the wizard.
- Determining which service should be
selected by default to use for a given subsystem. In the wizard, the
user could change the selection if desired.
With that I wouldn't expect to have to do anything with
the new host contructor since this function really falls to the subsystem
level.
Does that make sense?
Or am I missing somethign you're
saying?
____________________________________
David McKnight
Phone: 905-413-3902 , T/L: 969-3902
Internet:
dmcknigh@xxxxxxxxxx
Mail:
D1/619/8200/TOR
____________________________________
javier.montalvoorus@xxxxxxxxxxx
03/07/2006 12:06 PM
|
To
| David McKnight/Toronto/IBM@IBMCA,
david_dykstal@xxxxxxxxxx
|
cc
| martin.oberhuber@xxxxxxxxxxxxx
|
Subject
| Registering discovered services
in RSE |
|
Hi,
I'm trying to add service discovery capability to
the RSE wizard and I'm having some issues that you might be able to
clarify.
RSE hosts are organised in systemTypes (i.e Unix, Windows...), so
it implies always using the predefined lists of services when a specific
system type is selected.
In service discovery, knowing the services that
will be discovered is not possible , only it is possible to know the potential
services to be discovered and its identifiers ("ftp", "ssh"...). This
information has to be provided somehow in the plugins. At the moment I provide
this info through 2 new system type entries, one generic for all SD capable
("Discovery") and one specific to the service("ftp", "ssh"...)
What I have achieved since
now is:
1-
Each plugin for service discovery provides 2 new entries for system
types, one generic (for all services, "Discovery") and one specific to the
service plugin
2-
The specific one (let's say "ftp"/"ssh"/"telnet") is used to load the
required extra wizard pages
3- Start the wizard and discover a new host with a list of
services.
4-
When finishing the wizard, a new host is created, but since only a
systemType can be passed to the constructor, passing "Discovery" as a system
type creates a host with entries for all the discoverable services, not
only for those discovered.
Do you know how could I manage to create a host
containing only services discovered at runtime ?
Many thanks,
Javier
Montalvo OrĂºs
Engineering Tools
Symbian
Software Limited.
Tel: +44 (0)207 154 1091
*******************************************************************
***
Symbian Software Ltd is a company registered in England and
Wales with
registered number 4190020 and registered office at 2-6
Boundary Row,
Southwark, London, SE1 8HP, UK. This message is
intended only for use by
the named addressee and may contain
privileged and/or confidential
information. If you are not the
named addressee you should not disseminate,
copy or take any action
in reliance on it. If you have received this
message in error
please notify postmaster@xxxxxxxxxxx and delete the
message and any
attachments accompanying it immediately. Neither Symbian
nor any of
its Affiliates accepts liability for any corruption,
interception,
amendment, tampering or viruses occurring to this message
in
transit or for any message sent by its employees which is not
in
compliance with Symbian corporate policy.
*************************
*********************************************