RE: [A5:RT] Minimum J2ME Specs and Strategy

> From: Daniel S. Haischt [mailto:[email protected]]
> 
> just a few notes ...


Good stuff, here are a few reactions:

>  3) i don't understand why someone would be interested
>     in implementing a A5 container on MIDP. you should know
>     that the memory limit is mostly around 100KByte on those
>     devices and if you start using a XML parser i will reach
>     that limit very soon.
> 
>     even if you'll manage to stay within that range doesen't
>     mean that there is enough space left to run an app in that
>     container.

I am trying to propose something that does not require the
existence of an XML parser.  I.e. the XML descriptors that
you develop with are compiled into bytecode for the J2ME
systems.  With a concrete class that has hard coded return
values, you don't need an XML parser.


>     i am now developing about three years with J2ME and it was
>     allways a challenge to bring both, business logic and the
>     app server, on a MIDP device. for example, if you manage to
>     run both the container and the app on a Palm Pilot (which
>     supports MIDP), there would still be the raimaining problem
>     that it takes about 5 - 10 minutes to start the whole thing.

That is a problem.  Do you know what it is that causes the 5-10
minute startup time?  If we generate classes from descriptors that
effectively control the component according to the descriptors--
but with the constraint that it cannot be changed, wouldn't that
speed things up tremendously?

>     so the ultimate choice would be CDC/Personal Profile/PersonalJava.

Ok.  I understand your point.  I am not experienced with J2ME
programming, but I am willing to learn what I need to.

> 
>  4) speaking about XML parsers - if you decide to stick with
>     MIDP i would suggest the following XML parsers.
> 
>      - kXML 2 -> http://kxml.org/
> 
>      - XPP -> http://www.extreme.indiana.edu/xgws/xsoap/xpp/index.html
> 
>     IBM's developerWorks did some performance tests and
>     as i remember kXML 2/XPP are outperforming kXML 1.

Again, I would want to provide a system where XML parsers are
unnecessary.  Micro Edition containers do not need to be dynamic.


>  5) there is already a J2ME JINI environment. allthough i wouldn't
>     use JINI as an argument for CDC, cause in most cases you might
>     consider to use the J2ME JXTA client. and last but not least
>     there are already some Linda Tuplespace implementations for
>     J2ME which are providing many JINI like features.

COuld you elaborate on what JINI really brings to the table?  How
does it help or compete with Avalon?  I really am speaking from a
point of ignorance here so I would like to know.