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

hello,

> -----Ursprüngliche Nachricht-----
> Von: Berin Loritsch [mailto:[email protected]]
> Gesendet: Montag, 6. Januar 2003 14:05
> An: 'Avalon Developers List'; [email protected]
> Betreff: 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 working for a client, that is trying to do exactly the same.
they are defining GUI interfaces (SWING/AWT/MIDP) using XML files.
the GUI interface will be build dynamically by using the XML file.

the problem is - reading XML files on a MIDP (Palm etc.) device is
a real performance drawback. so the only solution is to write a parser
that reads the XML descriptors and compiles them into Java bytecode.

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

the proplems are ...

 1) omit reading XML files on MIDP devices if possible.
    just consider that if you are accessing a SOAP driven
    web service using a cell phone, the user has to pay
    for the time the app needs to parse the SOAP envelops
    which were sent over the wire.

 2) don't read a XML file at once. instead read each node as
    needed. if node A references node B, read node A but not
    node B. just store the reference to node B and resolve it
    if the app needs to access node B.

 3) another problems are validating parsers. for example if
    you are using XML descriptors that need to be validated
    against a DTD/Schema, you will definitly experience some
    performance issues.

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

first of all i was mentioning JINI, cause Noel J. Bergman mentioned
'having more sophisticated device, including more computing power,
goes some kinda convergent to Sun's strategy of having a JINI client
on every device'.

i don't know whether cell phone vendors and consumers will agree that
they need a JINI environemnt on their device.

the idea behind having JINI on PDAs/Cell Phones is, that it enables
transparent service lookups, which in turn simplifies location based
services.

an example - if you enter an airport your PDA would be able to transparently
lookup a ticket booking service. that way you would be able to book you
flight very easily. allthough having a WLAN card or a GPS sender would be
a must.

another example - you are reading a document using your PDA. in front of you
there are some printers but you don't know how to use/configure them on your
PDA. having a printer service that could be transparently looked up without
an user interaction could solve the problem.

but now comes my argument why JINI sucks, on MIDP devices (aka cell phones).

AFAIK - JINI requires your cell phone to communicate via RMI. there is just
one problem: MIDP does not ship with any RMI classes. in MIDP 2.0 you could
use sockets, HTTP and HTTPS connection - but that's it.

i mentioned Linda Tuplespaces, because there are some Java implementations
that provide transparent service lookups, but they do not require you to
communicate over RMI (for example, IBM's TSpaces or Lime a sourceforge
project).

not communicating over RMI but for example over HTTP/Sockets would enable
other
none Java devices to use those services, too. for example a .NET Compact
device
could access services offered by the A5 container. .NET Compact is the M$
equivalent to J2ME.

but as i said - i just mentioned JINI again, cause Noel was mentioning that
Sun might push better mobile devices cause the do have a interest in rolling
out JINI onto every device.

regards

daniel s. haischt
--