Re: [Embedlets-developer] Catching up on the postings.

[Brill P. <bri...@ro...>]

I've been chatting with Andrzej in private e-mail (I guess it should have
gone to the list) about the XML thing...
He basically filled me in on some of the stuff I missed over the holiday
"break" we had, and I'm now up to speed.

Anyway, no more argument from me about the XML, as when built right it won't
matter.

- Brill Pappin
  Rogue Robotics
  www.roguerobotics.com

----- Original Message -----
From: "Christopher Smith" <cs...@oo...>
To: <emb...@li...>
Sent: Tuesday, January 28, 2003 9:17 PM
Subject: [Embedlets-developer] Catching up on the postings.


> In reviewing the postings of the last couple of weeks it appears that a
> solid development path has yet to be laid and the project members have not
> yet achieved consensus on the priorities and division of effort. This is
> natural for a startup project such as this. Some of the issues are sticky
> and contentious others are generally agreed on.
>
> May I suggest that:
>
> 1. A list of the issues/tasks be created and  prioritized
> 2. Each task gets portioned out to one or two individuals based on skill
and
> desire
> 3. The results of the efforts posted to cvs as ready
> 4. A discussion thread for each task is created open to the group as a
> whole.
> 5. Contentious issues can be tabled for later resolution in favor of those
> that can produce real results in short order.
>
> A two level list might look like:
>
> 1. Container specifications
> add/remove/locate methods
> embedlet instantiation and population
> life cycle
> RPC methods (getEmbedletPropeties, setEmbedletProperties, start, stop etc)
> 2. Embedlet specification
> container facing interface
> persistence interface
> life cycle
> error management
> 3. Event API
> Listener
> Source
> Methods
> RT thread issues
> 4. XML persistence and serialization
> Properties interface (getProperty(), setProperty())
> XML schema (not necessarily enforced)
> parser selection and minimal requirements (SAX, DOM, unidirectional pull?)
> 5. Communication protocol
> Request/response
> retry recovery
> socket pooling and management
> 6. Storage (local persistence)
> CLDC based?
> Stream or database?
> 7. GUI specifications
> Java bean subclass
> Design paradigm
> 8. Web services specification
> http/XML envelope
> SOAP transport
> JSP/J2EE/ASP/.NET examples
> 9. Mobile and wireless specifications
> CLDC/MIDP
> Socket/proxy requirements
> parser
> configuration
>
> Obviously a list like this needs to be distributed amongst the developers
> involved,  although we will all have strong opinions in some or all of the
> areas our efforts should be directed at generating a solid, simple
> specification and reference implementation that can be understood and
> accepted.
>
> Finally (if you have not lost interest), I would like to offer to
contribute
> a large body of work on a implementation that embodies a number of the
> concepts envisioned in Embedlets. I am offering to present the API and
> implementation for critique, inclusion in or conversion to the Embedlets
> specification and/or as the basis for a reference implementation. I see
this
> code base as a good head start that proves the concepts of Embedlets but
> requires conformity to a standard that will endure and be accepted by the
> embedded community at large.
>
> Sorry for the dissertation, I got carried away on my first posting.
>
> Christopher Smith
>
>
>
>
> -------------------------------------------------------
> 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