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

[Holger B. <ho...@bi...>]

FYI: meanwhile the DNS Server service is deprecated (same like NIS and 
friends), it make more sense to use an LDAP for this tasks.

bax

Am Mittwoch, 19.02.03, um 23:52 Uhr (Europe/Budapest) schrieb 
Christopher Smith:

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