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

[Christopher S. <cs...@oo...>]

>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> 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.

It may actually make a lot of sense to use a DNS to keep a database of ips,
since that is what they do. It would be especially useful in a large
installation such as an oil refinery:

http://holdingTank114.elsugundo.unionoil.com:8180/tankMonitor/oilLevel

This assumes that there can be more than one container at a given ip
address, the container address would be omitted if not.

The address resolution would be distributed to each level of the hierarchy:
DNS(domain)/IPDaemon(port)/Controller/Container/Embedlet

>
> 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).
>

There should be a name AND an identity (you may have stated this but I just
wanted to emphasize to point). The name is used for human consumption and
can change, the identity is fixed for the life of the configuration and is
used for internal reference.

> 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
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>