regarding the 5 - 10 minutes startup time: - i did not pay attention that you were asking whether it would speed things up if each XML descriptor would be compiled into bytecode.
in that case i would say, that the startup time would be something about 0.5 - 1.0 minutes. allthough you need to stay within the 100K - 200K memory limit (container + app). but that could be only figured out by programing a A5 container J2ME prototype which could be tested within the Sun Wireless Toolkit 2.0. regards daniel s. haischt -- > -----Urspr�ngliche Nachricht----- > Von: Berin Loritsch [mailto:[EMAIL PROTECTED]] > Gesendet: Montag, 6. Januar 2003 16:04 > An: 'Daniel S. Haischt' > Betreff: RE: [A5:RT] Minimum J2ME Specs and Strategy > > > > > From: Daniel S. Haischt [mailto:[EMAIL PROTECTED]] > > > > hello, > > > > > Von: Berin Loritsch [mailto:[EMAIL PROTECTED]] > > > > > > 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. > > Right. That is the solution I am proposing as well. > > > > > > 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. > > Right. That is an App specific requirement that the Avalon user > needs to be aware of. > > > > 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. > > Again, this is only if you use XML in the runtime. > > > 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. > > In a constrained environment, I am sure that more logic will > be placed on the server to ensure proper validation than on > the client. But again this is only if you use XML in the > runtime--and I want to get away from the misconception that > it is a requirement in order to use Avalon. > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
