RE: [Embedlets-dev] [Arch] Separating business logic and hardware layers

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

>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Brill suggests:
>
> > Now the question as I see it, is how much do we try and make the two
> > dependant from one another... if they are, we will loose flexibility and
> > the ability for developers to use the japl without Outpost, however if
> > they are not we will expand the size of our code to some degree (or so I
> > would assume).
>
> I think they should be decoupled as much as is humanly possible.  Tight
> coupling in that area would be disastrous from a flexibility and
> maintenance
> perspective.
>
> A developer should be able to use Outpost/Embedlets with or
> without JAPL.
> Similarily, JAPL should not depend on Embedlets.  The one is a container
> architecture, the other is a hardware abstraction layer.  They need to be
> distinct.
>

That would be my vote as well. There are often cases where an Embedlet
developer may do his own I/O processing. This would make the Embedlet
platform-dependent but that may be acceptable for a simple extension to a
set of off-the shelf Embedlets. In other cases the I/O is already supported
by a published API for example: comm or Dallas one wire. Here is would be
pretty inefficient to place a JAPL layer in the middle.

As JAPL take hold and all IO chip makers, Java VM and board vendors comply
the need for this flexibility will diminish.


> 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
>