Digging into the API

[Kimbro Staken <ks...@xmldatabases.org>]

Here's my initial comments on the proposed API.

EncodedBuffer should probably be renamed to something more useful, maybe 
CompressedDocument.

EncodedBuffer should probably be a subclass of Hashtable and just maintain 
the instance data as members of the Hashtable. This will allow the RPC 
library to serialize it directly. I'm thinking the sym and buf should be 
base64 encoded strings. And the class should just provide methods to 
convert byte[] to and from that form. I don't think it should contain byte[
] instance variables. Also it should have methods to take a Document 
instance and initialize itself from that and also to retrieve a document 
instance.

Also in the implementation sym and buf should really be given better names.
  Maybe symbolTable, documentContent and stamp should just be timeStamp. I'
ve always found the current names ugly and confusing.

I don't understand the need for CollectionHandle? I'd just prefer to see a 
string used unless there's a really good reason otherwise.

I don't think we need DatabaseService, everything should just go through 
CollectionService. Not sure about KernelService yet.

NamedVal is another thing that if kept will need to be a Hashtable. I'm 
not sure we really need it though. It's probably just as easy to have an 
array of hashtables directly. Also if it's kept it should probably be 
renamed to something like Namespace.

When added to the tree, most of these classes shouldn't be part of the 
client package. They're really server side only. EncodedBuffer and 
NamedVal are the only exceptions that will be used on both the client and 
server. I know the CORBA servants are in that package, but I never 
understood why the servant classes were moved into the client package 
either.

There's several things we'll need to change in the CollectionService 
interface, basically added functionality that is missing from the current 
API. This would be things like meta-data about documents, collections, 
indexes and so on. Once we get the general shape of the API worked out we 
can dig into this in more detail.

Kimbro Staken - http://www.kstaken.org - http://www.xmldatabases.org
Apache Xindice native XML database http://xml.apache.org/xindice
XML:DB Initiative http://www.xmldb.org
Senior Technologist (Your company name here)

Re: Digging into the API

[Kimbro Staken <ks...@xmldatabases.org>]

On Wednesday, March 13, 2002, at 05:04 PM, Kimbro Staken wrote:
>
> NamedVal is another thing that if kept will need to be a Hashtable. I'm 
> not sure we really need it though. It's probably just as easy to have an 
> array of hashtables directly. Also if it's kept it should probably be 
> renamed to something like Namespace.
>

Thinking about this a little more, I believe we should avoid having this 
as a separate class. If we do that then the only difference between the 
compressed API and the uncompressed API will be replacing all the 
EncodedBuffers/CompressedDocuments with Strings.

Also I don't think the stamp parameter on queryCollection is necessary 
anymore. Tom can verify this, but I believe it was only used to determine 
if the result should be compressed or not. Since we're using two endpoints 
we already know the answer to that question.

Kimbro Staken - http://www.kstaken.org - http://www.xmldatabases.org
Apache Xindice native XML database http://xml.apache.org/xindice
XML:DB Initiative http://www.xmldb.org
Senior Technologist (Your company name here)
>