OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal

[ Lists Home | Date Index | Thread Index ]
  • From: "Don Park" <donpark@quake.net>
  • To: <xml-dev@ic.ac.uk>
  • Date: Sun, 14 Dec 1997 09:10:23 -0800

Peter,

>Poor old JUMBO comes to 500 Kbytes at least if it's all there. That
>includes things like matrix.diagonalise(), ProteinSequence.Align() and
>Bivariate.display(Axes). I am assuming that (a) things will speed up (b)
>classes can be cached client-side (c) the excitement of finally getting the
>display will hold the reader in her seat long enough. I'm certainly
>assuming that JAR files will happen (or equivalent). IOW I'm not designing
>for speed, but functionality.

Problem with relying on cached Java classes is that a typical browser user
will flush the cache quite frequently (everyday in my case because one day
of work leaves me with about 25 to 50 meg of useless web pages and images in
my cache).  I would prefer to leave the Java classes in the cache but
current crop of browsers offers little control when it comes to cache
content.

My advice is to solve the download problem from user perception angle.
Users expect applets to download fast (1 to 5 minutes) because they are
expecting to see the applet as part of a web page.  Their focus is on the
content and not the code.  They do not realize emotionally that content must
be rendered by applets and applets take time to download.  On the other
hand, when they are asked to manually download something and install it,
they display more patience because they know they are downloading software
and not content.  They are already familiar with the timescale of getting
and installing new software so wait of 10 minutes to 1 hour is not going to
tick them off.  One added bonus is that, since you can install into
browser's classpath, you get higher security clearance.

If you really need to go the download-on-demand applet route, you can divide
up your classes into two parts.

First part is a small set of classes with following objectives:

1. Put something up to grab user's attention.  Amuse him with something or
render non-editable view.
2. Prefetch resources such as XML files and the second part.

The second part is the full set of classes.  The point is that something
like your XML browser applet will usually display some XML files which are
not fetched until all the classes are downloaded unless they are prefetched
using a scheme like the above.

Hope this helps,

Don Park




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS