RE: [Embedlets-developer] Lots of posts...

[James C. <ca...@vi...>]

Good to see you back in form Andrzej

1) I totally agree that a XML backend is what we are after. And that any
graphical viewer is just a visualiser for that XML. That is exactly the
approach I have taken in VBB. (Which is a VB front end and Java BackEnd -
openVBB). I would like to keep the XML as simple as we can to begin and grow
it upwards from there but if we can come up with the rich version up front
then I am happy with this also. My issue is that we are collectively don't
have 1000's of man years of knowledge in the fields of its actual
application - as a group we seem better at theory and abstraction than hands
on application. SO the thinking was to keep it simple as possible and move
upwards.

2) I don't agree about the PLC as 'not important' are you kidding? It is
probably the biggest field of embedded engineering out there!? However I
think there has been a little confusion, I am not suggesting PLC's run
embeddlets - actually I am suggesting the other way around, that embedlets
can run PLC code.
Specifically, I want a Ladder Logic ==> Embedlets.xml translator so that
java devices running the embedlets framework can run PLC code. I think this
is enourmously valueable. Furthermore in building this translator I think
there are valueable lessons to be learned about the embedded domain - there
is ALOT* of overlap between PLC's conceptually with embedlets forgetting
that Ladder Logic is a pretty much redundant way of representing executable
code but it is a standard. The fact that openPLC are coming out with an XML
representation is exciting because perhaps the  Ladder Logic ==>
Embedlets.xml is simply an XML transform of the openPLC.xml schema.

3) Yes, I am considering making VBB 'open source' It has alot to offer,
openVBB is pretty much an implementation of the Outpost like Container. It
uses a java backend with most of what we have been talking about with java
objects created by reflection and an event driven SignalProducer/Consumer
wiring model which can handle both synchronous(clocked) and
aysnchronous(change-response) logic operators and has a XML-SVG component
representation to boot.

>Embedlets are supposed to be open source.
4) No the standard and reference implementation will be open source. I think
there will be many commercial implementations of the standard and don't have
a problem with that. Not all TCP/IP stacks are opensource yet they implement
a standard!

James


BTW - This replytoall and then edit out the author to reply to the list is
confusing. Is this what we all decided was the prefered mechanism? I would
prefer reply to go to the list..

> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Andrzej Jan Taramina
> Sent: Monday, January 27, 2003 9:33 AM
> To: emb...@li...
> Subject: [Embedlets-developer] Lots of posts...
>
>
> ...can you tell I've been trying to catch up?  Anyhow...it should
> hopefully spark
> some more design discussion.
>
> I've been doing a lot of investigation in the Avalon framework (I
> think we can
> adopt some of the principles, but in the short term AV5 won't be
> ready soon
> enough for use...we could retrofit later if there was any desire
> to), and also into
> JMX.  Some ideas are starting to gel on how to provide a flexible
> container
> architecture, with optional JMX management features for Outpost.
> But I have
> a bit more work to do, and some prelim design before it'll be ready for
> discussion.
>
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>