> -----Original Message-----
> From: Kimbro Staken [mailto:[EMAIL PROTECTED]
> Sent: 14 March 2002 01:05
> To: [EMAIL PROTECTED]
> Subject: Digging into the API
>
>
> 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.
Is this not a task that whatever RPC toolkit is used should perform?
> Also it should have methods to take a Document
> instance and initialize itself from that and also to retrieve
> a document
> instance.
>
Makes sence
> 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.
>
You sait it :) Took me a while to figure out that "buf" was actually
compressed XML...
> 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.
>
Well, that was basically it. The idea behind CollectionHandle is just to make
sure
whoever's using the API on the client side isn't too aware that he's using a
string.
On the other hand, if there is a unqiue string associated with each collection
in a database,
that actually makes sence to the client, I'd rather use that too. How about the
complete path
to the collection?
> I don't think we need DatabaseService, everything should just
> go through
> CollectionService. Not sure about KernelService yet.
OK. Indeed all methods of DatabaseService could be run on what might be
considered
the "root collection", i.e. the database.
>
> 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.
Why an array? one single hashtable using namespace prefixes as keys and
namespace uri's as data
would surely suffice? That's how I ususally pass a set of namespace bindings.
>
> 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.
>
OK. I was thinking that same thought, but knowing the history of CORBA in
Xindice, I just used
it as a guide... server package would definately be more logical. Probably a
structure like:
rpc/api => The interfaces (which should be used in BOTH client and
server)
rpc/client => anything client related
rpc/server => server implementations of classes
/common => EncodedBuffer and (if kept) NamedValue
would be more appropriate?
> 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.
>
OK, can some other folk help with this, as I'm not sure what this extra
functionality should be?
I'll try and get going on the other issues raised here.
James
> 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)
>
>
