geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: Geronimo Deployment Descriptors -- and premature optimisation
Date Tue, 09 Sep 2003 22:15:18 GMT
On Tuesday, Sep 9, 2003, at 22:35 Europe/London, Jeremy Boynes wrote:

>> From: Alex Blewitt []
>> 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.

My interpretation of 'compile' was 'translate into a binary format'. It 
could, of course, mean translating to any formats, not just binary.

> For example, it could be an archive of serialized MBean
> states that can simply be unmarshalled by the server and started.

Yes, this is one possible way of doing it, but I tried to address the 
risks with a binary approach that this could take.

> This has
> many potential advantages, such as reducing the startup time for very 
> large
> applications or reducing the resources required for an embedded 
> server."

I did disagree with the fact that it will reduce the startup time. This 
is based on nothing but speculation.

It also may not necessarily be the case that it will reduce the 
resources required for an embedded server; if, for example, other 
aspects of the core require an XML parser to be present (for instance) 
then the size may stay the same.

However, I do agree that there are several formats and options we could 
use with advantages and disadvantages.

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

I believe that avoiding using XML because of feared performance is 
premature optimisation. I don't believe that I said 'excessive', though 
I may have done.

And, whilst it is good to explore other ideas and issues, it's also 
good to be able to discuss the advantages and disadvantages of the 
approaches. That isn't to say that this approach shouldn't or couldn't 
be taken, but there are some disadvantages to which the advantages may 
not be enough.

> Please do not misrepresent me.

I do not recall misrepresenting you, but I apologise if I did. I merely 
tried to point out some problems with a compiled and/or binary approach.


View raw message