[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

• From: Peter Murray-Rust <peter@u...>
• To: David Megginson <ak117@f...>, Tim Bray <tbray@t...>
• Date: Sun, 14 Dec 1997 15:29:50

At 06:35 14/12/97 -0500, David Megginson wrote:
>Tim Bray writes:
[...]
> > 
> > Hmm, isn't this what JAR and so on are for?  Seems like an awfully 
> > severe design constraint.  I certainly agree with "small" as a design
> > goal, but it seems like limiting class file count carries a pretty
> > high price. - Tim

The following assertions are based on ignorance and hearsay...

As I understand it, if Java wants a method in a class, it loads the whole
class into the virtual machine.  Therefore if you have a large complex
class you have a constant large overhead in terms of (a) HTTP connections
(b) JVM space. I have a number of very large classes (e.g. > 100 member
functions, some quite crunchy) so I have been thinking of doing the exact
reverse to DavidM - i.e. splitting up my classes into smaller bits.  Thus
my MOLNode implements Drawable routines, Linkable (XLL), Editable,
Validatable at least. If I have a very simple application it will still
download all these functions (am I right?) and also keep them in the JVM so
long as there is a re ference to an object of the class (am I still right?) 

So I am thinking of splitting these into smaller chunks, such as
DrawableMethods, etc which don't need to be loaded if not used.  Would the
same apply to AElfred?  Thus if you had two chunks - DTD.class and
Instance.class (or whatever) and the document instance had no DTD, you'd
never need to load the DTD class, right?

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. 

	P.


>
>It is a painfully high price, especially in terms of coding
>difficulty; if NS 3.*, NS 4.*, MSIE 3.*, MSIE 4.*, and HotJava all
>accepted the JAR files (or any other archive format), then I wouldn't
>worry.  As it stands, however, that is not the case, and it is
>essential that Ælfred be easy to use in existing browsers as well as
>future ones.  That is the same reason that I didn't use any JDK 1.1
>features, despite the fact that I _like_ JDK 1.1.

I would assume it's possible to re-route the client to a non-JAR applet if
required.

	P.
	
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

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

• Follow-Ups:
  • Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal
    • From: "Mark L. Fussell" <fussellm@a...>

• References:
  • Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal
    • From: Tim Bray <tbray@t...>
  • Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal
    • From: David Megginson <ak117@f...>

• Prev by Date: Re: YAXPAPI and DOM
• Next by Date: Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal
• Previous by thread: Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal
• Next by thread: Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal
• Index(es):
  • Date
  • Thread