Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 35204 invoked from network); 6 Jan 2003 16:09:03 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 6 Jan 2003 16:09:03 -0000 Received: (qmail 13429 invoked by uid 97); 6 Jan 2003 16:09:41 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 13364 invoked by uid 97); 6 Jan 2003 16:09:39 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 13292 invoked by uid 98); 6 Jan 2003 16:09:38 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) From: "Daniel S. Haischt" To: Cc: Subject: AW: [A5:RT] Minimum J2ME Specs and Strategy Date: Mon, 6 Jan 2003 17:07:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <000401c2b594$c6a710a0$f700a8c0@acsdom1.citius.com> Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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:bloritsch@citi-us.com] > 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:daniel.haischt@daniel-s-haischt.biz] > > > > hello, > > > > > Von: Berin Loritsch [mailto:bloritsch@citi-us.com] > > > > > > 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: For additional commands, e-mail: