[news.eclipse.technology.eilf] Re: [Xml Storage] API :: first draft

[Jürgen Schumacher <juergen.schumacher@xxxxxxxxxxx>]

Hi,

some comments inline ...

Am 06.05.2008, 13:31 Uhr, schrieb tmenzel <tmenzel@xxxxxxx>:
> another item i might want to put here is the client's default collection  
> if we have more than one and these are not transparent to the user.
>
> collections, as far as i can tell, are not 100% defined as to what they  
> represent in each implementation of Xquery but may be used to represent  
> diff. data stores or SEGEMNTs of the same store, etc. and that is smth.  
> we might want to control on the client side, e.g. as a private temp  
> storage etc.
>
> on the other hand we might decide to put that one level higher and make  
> that part of the config, such that one service only represents one  
> collection and u would have to connect to another service that  
> represents another collection.

I think it would be OK to have the several collections of one XML database
accessed via a single XSS service, it would make implementation of clients
and service deployment easier: One XSS service instance represents one
physical XML storage (server? I'm not quite sure about the terminology
yet) and everything in this storage can be accessed via this service.

If so: Would it make sense (be possible?) to have some collection  
"management"
methods in XmlStorageService? E.g. getAvailableCollections,  
createCollection,...?

> as u can see: i'm not quite sure on the subject

Hope this helps to make up your mind (-:

> > - About the XssConnection methods: I wonder if we could need bulk  
> > mehods like addRecords(Record[]), or simply make the existing methods 
> > take a variable number of arguments, e.g. addRecord(Record...) to be 
> > able optimize performance?
> possible, but i tried to resist the temptation of offering too many  
> convenience methods at this time. once the API is stable and we got some  
> experiences, we may add such methods. before that, adding some helper  
> classes should be the way to go IMHO.

That's OK for the moment. Just wanted to add that these would not be pure
convenience methods that could be moved to helper classes but that they
should really optimize something when talking to the actual database
server.

Cheers,
Juergen.