[Embedlets-dev] [Off Topic] re: ID'ing peripherals

[Andrzej J. T. <an...@ch...>]

Brill asked and Chris responded:

I don't think this is off topic at all.....components (embedlets, services, 
adapters and devices) will need internal names, along with a name for the 
Outpost container itself.  

> The container should have a unique identity that could be concatenated with
> the embedlet/JAPL id.
> 
> Since the devices are likely to be at the end of a DNS, it would probably make
> sense to structure the path as a URL:
> 
> http://targetDevice.mycompany.com:port/containerID/EmbedletID/JAPLID

If a company has thousands of embedded processors deployed, it's unlikely 
that they will use DNS names for them, since maintaining that many DNS 
entries is a big task.  More likely they will just allocate IP addresses.

That being said, the idea has merit.  What I'm planning to put in the spec is 
that the user will be able to assign names to all the components and the 
container (as strings) in the XML Config files, and in the case of the 
container itself, allow this to be overriden in the deployment process (so 
that multiple identical containers can had unique names).  But I was not 
planning on specifying what the names should look like....would rather just 
allow any arbitrary string, and let the client use whatever naming standard 
makes sense for them (since they may already have corporate standards for 
this).

Brill continued:

> Sure... though I wasn't trying to come up with an ID for embedlets and it
> needs to work without an embedlet system present. however that is certainly a
> workable solution.

I'ld be wary of imposing naming conventions, since clients may already have 
their own.  Just provide a name string, with getName()/setName() methods.  If 
the JAPL device is running under the control of an Embedlet Container, then 
the Embedlet would likely read the device id from the XML config file and 
issue the setName() property on the devices behalf.

> Yes, that's pretty much what I'd like to do... what I need to decide is how
> the id is generated etc, and who names the container?

If we provide a generic, string-based naming ability, the client can do 
whatever makes sense for them.

> So, the id's can be auto generated during negotiation and start-up, or they
> can be named parameters in some sort of property set... for embedlets the
> named approach makes sense.

I would let the client provide the auto-gen id code as part of the deployment 
process.  


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com