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

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

> 
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
> 
> FYI: meanwhile the DNS Server service is deprecated (same like NIS and 
> friends), it make more sense to use an LDAP for this tasks.
> 
Roger that, DNS was being used in a generic sense. 
 
> 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
> >
> 
> 
> 
> -------------------------------------------------------
> 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
>