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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
