Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Development" <avalon-dev@jakarta.apache.org>
Message-ID: <3BDABF90.7070009@yahoo.com>
Date: Sat, 27 Oct 2001 15:07:12 +0100
From: Paul Hammant <Paul_Hammant@yahoo.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.5) Gecko/20011011
MIME-Version: 1.0
To: Avalon Development <avalon-dev@jakarta.apache.org>
Subject: Re: New JDBC server for phoenix
References: <3BD973BA.9090003@yahoo.com>
 <200110270318.f9R3Itu23602@mail012.syd.optusnet.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Peter,

Thanks for the weighty reply.  I agree with everything you've said. 
 When I get it to a point of significance, I'll commit it and hope 
others can join in a melee of refactoring.

- Paul H

>On Sat, 27 Oct 2001 00:31, Paul Hammant wrote:
>
>>Folks,
>>
>>Given that InstantDB is not going to be open after all. ( see
>>http://www.simpledb.org/  ), I have possibly foolishly though of
>>starting a clean DB server along the lines of InstantDB and Hypersonic.
>> The idea is that it sits in Cornerstone/apps and uses as many
>>phoenix/excalibur concepts as possible.  It would ultimately lean on
>>many different configurations (assembler duty) of persistence (or not)
>>and wire transport.  If it gets critical mass and moves beyond "sample"
>>status, perhaps it could be grated project rights at Jakarta.  For now
>>though it's a solid Avalon hosted sample application of some size.  I've
>>actually coded a little of it already...
>>
>
>I like it. One thing I would like though is to create it as a set of 
>components. Assuming you are going with a relational DB, a possible 
>decomposition would be something like
>
>Database stuff:
>* index generator: maybe general purpose BTree classes that could easily be 
>replaced (ie pure memory based BTree vs mixed disk/memory Btree vs...). 
>Perhaps you could use that toolkit I pointed out a while back?
>
>* flexible persistence layer: (ie how indexes + rows + column datatypes are 
>stored on filesystem) 
>
>* Schema model: separate classes to represent schemas of a database and each 
>row. Things like ColumnMetaData, TableMetaData, IndexMetaData, 
>ClusterMetaData etc. Hopefully useful outside of database aswell so tools 
>like Turbines Torque could use it
>
>* SQL parser: a semi generic parser that could be replaced with parsers for 
>different syntaxs in some cases. The parser would generate the Abstract 
>Syntax Tree. (I know quite a few projects havce such a thing - I think 
>Turbines Torque has a cutdown version of this)
>
>* SQL optimizer: separate module to optimize the SQL AST based on a specific 
>Schema
>
>Network stuff:
>* encoders/decoders: Separate encoding out from actual users of encoding. 
>Some encoding examples could be BER (from ITF world), JRMP (ie default RMI 
>protocol), XDR (like used in NFS), IIOP (Corbas default protocol), SOAP etc
>
>* syntax layer: ie how encoding is used (ie the signatures of the 
>RMI/IIOP/SOAP methods etc).
>
>* transport: ie TCP, SSL etc
>
>
>
>It would also be useful to reuse parts of existing projects (or proposed 
>standards) if at all possible. I would be quite happy to help creating  
>network stuff (because I am doing that anyways for another project).
>
>I also know of a few people that will want to use just parts of it. I could 
>quite easily see a LDAP server using network/index parts or a object database 
>using the persistence/index + network stuff. 
>
>Anyways sounds like a great idea. 
>
>>Then again, maybe Cornerstone is not the place.  Thoughts?
>>
>
>maybe not. But for now it could be a useful testing grounds until you get it 
>up and running ;)
>


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org