Re: [Embedlets-dev] Re:[HW] cvs module for JAPL

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

> > Ted, can you (or have you already?) create a CVS module for the JAPL
stuff
> > please (I'm assuming you are the fellow to talk to about this).
>
> Yes, it is src/org/japl but this is just an experimental directory
structure so
> start putting stuff in there and we can always refactor the directory
structure
> later if needed.

If its not too much trouble, I thought a separate module would be a good
idea... it could then have its own build environment and documentation... at
the moment there is no source, I just wanted a place to put any docs I write
so that if I drop off the face of the earth, its all saved... and people can
see how its progressing.

> > I've started this by creating a UML class diagram to help get my head
> > straight around what is needed...
>
> Well, this is good!  I am a big fan of UML and I think others on this list
are
> too (I assume that since Andrzej lists Together as his top end IDE that
this is
> the case with him too?).

heh... its pretty sparse at the moment... I've only now had time to sit down
and do some thinking. Anyway, I've attached a GIF of the structure
(hopefully you can read it) that I've come up with so far (only a few hours
today) but it will likely change quite a bit.

One thing I quickly realized is that its at the JAPL level that some form of
persistance or serialization ability must be integrated... or at least the
contract to do it, if not the actual act of doing it.
Anyway, I've left that part fairly "light" at this point with a "Storable"
interface (named so to differentiate from "Serializable", which is not
exactly what is going on). The methods for it take a simple InputStream or
OutputStream, so that the actual impl can store it any way that makes sense
later (such as XML, or binary etc).
The Storable stuff is not set in stone of course and we can look at the way
it should actually be done later... I just wanted to add a "placeholder" now
with the bare minimum.

> I have already taken the liberty to register the following domain names on
> behalf of the project:
>
> 'embedlet.org' for the embedlets code base.
> 'embedlets.org' for the embedlets main web site.
> 'japl.org' for the japl code base.
>
> And I was really hoping these names would stick so that my investment
would not
> be lost! ;-)

<choke>, <choke>
I guess that sort of define the domains we'll be working under ;) however I
don't think the package names have to be domain names in this case (see my
previous post).

> I would be happy to pass the ownership of these domain names over to the
> project if we could figure out the proper way to do this.  The only
difficulty
> might be that japl should probably be a separate entity in its own right
(apart
> from Embedlets and Cork) because developers might want to use these
interfaces
> apart from either of these projects.

This is true, although cork will likely become part of whatever standard the
JAPL becomes, because really Cork is an impl of the JAPL... (although
written first, it has a lot of aspects of what JAPL will become).
For the moment, cork is its own entity, but I plan to update it to conform
to the JAPL as soon as there is something to conform to... in fact I was
thinking that along side JAPL could be put JHAL (Java Hardware Abstraction
Layer) which Cork has tried to do in providing a common hardware layer so
that the same code runs on a JStamp, uVM or a TINI.
I expect Outpost will help define the JHAL as the JAPL will have to
implement on top of it, and it will be required to run Outpost. It may be
that JAPL and JHAL are really the same, the processor is after all a device
the same as the JAPL defines, its just not a peripheral.

Sheesh... getting complicated! I'd love it if anyone on the list would like
to help define the JHAL standard... the number of processors I've used is
fairly limited (only about 5 or 6 different ones, and only a few run java).

Anyway, for now its just a matter of getting started, so a place to drop
documents would be good ;)

- Brill Pappin
  Rogue Robotics
  www.roguerobotics.com