> From: Andrzej Jan Taramina [mailto:[EMAIL PROTECTED]] > > 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?
We aren't done planning yet. We are looking at making the process of developing Avalon components easier, as well as provide a unified container that scales from very little to very large. It will be a question of "what features do I need?". > What features are you targeting towards the embedded arena? We just want it to work in the embedded arena. If you have a laundry list of features that you want to see, please let us know. > How far along is A5? We are just starting to seriously talk about it. There is definitely time for you to inject your comments and ideas. > What kind of timeline are you looking at for an A5 release? Hard to say. Avalon 4.1 is here and will be maintained in the interim. Having just started, I doubt you will see anything concrete in the very near future. > How backwards compatible will 5 be with 4.x? An Avalon 5 container will provide the tools to work with Avalon 4.x components. We will have test suites and everything to help guarantee the fact. > > 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..... I see. Any pointers you can provide will greatly help us. > 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. Would it work if you had a _compiled_ assembly? An assembly in Phoenix/Merlin speak is a group of components that work together to provide an application. Currently it is an XML file that is interpreted at runtime. An embedded device doesn't need the luxury of dynamic assembly, so providing a way to hardwire it with a class might help. That would take care of the bulk of the classloader related issues. > 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. Sounds good. > 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. That is an area that I am looking into. The Configuration objects have always meant to represent information that can be from a variety of locations. We just never got around to writing the LDAP backed configuration reader, or others. Again, hardwired classes that generate the configuration would probably work wonders--like for the assembly. > > 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. Still doable. > > 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. Right. > 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. There is nothing concrete yet. We have some scribblings on the Avalon Wiki about some ideas. http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonProjectPages The more you can give us about embedded Avalon requirements, the better we can shape the future. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
