geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Boynes" <>
Subject RE: Geronimo Deployment Descriptors -- and premature optimisation
Date Tue, 09 Sep 2003 21:35:02 GMT
> From: Alex Blewitt []
> Sent: Tuesday, September 09, 2003 1:32 PM
> On Tuesday, Sep 9, 2003, at 21:22 Europe/London, Dain Sundstrom wrote:
> > Alex in an embedded system you may only have a small prom available to
> > boot from.  Specifically, you may want to ditch the 1 meg for an XML
> > parser.  You may also have a small amount of memory and XML parsers
> > are known for being memory pigs (which is fine in a normal server).
> You can't seriously be comparing Geronimo's kernel to that of an
> embedded kernel, can you? Never mind that the JDK in its current form
> is way too big to fit on a small device.
> If you want to write Geronimo for J2ME, go ahead.
> If we're using J2SE, especially 1.4, then we can use the XML parses
> that it comes with.
> > Also we need to be open to other persistent forms.  The XML document
> > is simply a persistent form of data and we need to be open to other
> > persistent forms.
> Yes, provided that those forms are a declarative non-binary
> representation for the reasons already pointed out. As I said, I'm not
> a definitive fan of XML; I'd prefer to see JNDI/LDAP being used
> personally, but there are bound to be other alternatives. I was merely
> pointing out the flaws in the argument; that it was optimisation
> without benchmarking proving the case in Geronimo's loading time; that
> programmatic specs degrade faster than declarative specs, and that
> binary formats degrade faster than text formats.
> I think that that's a pretty open PoV :-)

I originally said:

"This allows us, if we wish, to pre-compile the configuration information
into other forms. For example, it could be an archive of serialized MBean
states that can simply be unmarshalled by the server and started. This has
many potential advantages, such as reducing the startup time for very large
applications or reducing the resources required for an embedded server."

which is hardly advocating excessive premature optimization, just
illustrating a possible future path.

Please do not misrepresent me.


View raw message