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

[tmenzel <tmenzel@xxxxxxx>]

Jürgen Schumacher wrote:
> just had a look at it. It's basically OK to me. Just two remarks:
> - I'm not sure about the getConnection(ConnectionConfig) method, but it 
> depends
>   on what will be contained in the ConnectionConfig: A client should not 
> have to
>   know about where a database server is running and how to connect 
> (authentication),
>   this should be hidden by the service configuration. If
> ConnectionConfig is meant
>   to describe this, then I think we do not need this method. 
correct, i see it the same way

> If it is
> meant to
>   contain just connection parameters like e.g. switching transactional 
> behaviour
>   on and off or other things to tune the connection for the conversation 
> to follow,
>   it's ok. I hope it get's clear what I want to say (-;

i had exactly the that in mind commit behavior in mind and possible 
other settings we might want/need in the future. as u can see from the 
default method i intend to have this method only for advanced usage or 
control over the connection.

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.

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

> - 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.


> Cheers,
> Juergen.


--
Thomas Menzel (aka: tom)