avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrzej Jan Taramina" <andr...@chaeron.com>
Subject RE: Suitability of Avalon for embedded environments?
Date Thu, 26 Dec 2002 17:27:58 GMT
Berin:

> Avalon Framework is very low weight, and it can work in just
> about any environment.  However, most of our more functional
> containers are not friendly to the Embedded environment.

That's OK.....I have no problem building a new embedded container from the 
ground up using the Avalon Framework....

> That said, we have an eye on the embedded arena for Avalon 5.

Can't let a teaser like that go by! 

What's planned for A5?  

What features are you targeting towards the embedded arena?  

How far along is A5?  

What kind of timeline are you looking at for an A5 release?  

How backwards compatible will 5 be with 4.x?

> As long as the JAR can remain in memory, we can access the classes
> that way.  I think we have a "virtual" file system API somewhere.

Even that is unlikely.  We'll be targeting devices based on the aJile Java 
chips....say the Systronix JStamp, which in it's base config has 512K Flash 
and 512K ram.  There is a plus version with 2M Flash ROM.  So space is at a 
premium of course!  We're also looking at even smaller devices like PIC chips 
with the impending uVM Java implementation.....

My gut feel is that classloading with be extremely limited (to only those classes 
known to be needed ahead of time) or will be done across a network 
connection, if at all.

Some of these platforms (the aJile ones) do have thread support...others may 
not.  So we'll have to make threading an "optional" part of the container 
implementation.

Also XML parsing can be problematic.....no way we can load something like 
Xerces on an embedded Java chip.  There are some very lightweight XML 
parsing libraries out there (kXML, 15kb or so)....but for performance reasons, 
we would only use them for external integration communications (eg. 
XML/SOAP over HTTP), and not for internal configuration and the like, which 
is so popular server-side.  We'll probably have XML-based config files, but 
might pre-parse them into condensed binary format or java classes (static 
finals work well for this since the java compilers can then prune your code of 
unused features automatically) for use on the embedded container.

> We would probably have to start with Tweety (in Excalibur) and
> add in what you need.  In Avalon 5, we will be able to create
> a container that works in the embedded arena.  Most likely, all
> logging would be turned off, since as you say disk access is an
> issue and logging is of dubious benefit on a PDA.  Using a
> NullLogger will disable all logging.

We're not talking PDA's...but true embedded controllers (think factory 
floor....plant controllers and such).  As for logging, there is some utility in 
that...we may choose to stream terse logs for critical events across a 
network....or maybe out across a JTag connection (parallel port interface).  But 
definitely logging would have to be optional in many cases in the embedded 
world.

> It is feasible, but it depends on how much funcationality you
> need.

Probably more accurate to say "how much we can realistically do" on such 
small platforms.

Anyway....I'm really keen to hear more details about Avalon 5, since this will let 
me make some decisions as to how to proceed with our embedded container 
project.

Thanks!
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message