Re: [Exist-development] Moving towards a new API

[Jason S. <js...@in...>]

I was thinking about remote/local too.  That is certainly something that could be done with just a little planning.  

Where is the best documentation on the Fluent API?  I guess I should take a look.  I didn't use it originally because when I started this, Fluent was in its infancy...  :-)


-----Original Message-----
From: Eugene Marcotte [mailto:eu...@em...] 
Sent: Tuesday, September 07, 2010 4:17 AM
To: Jason Smith
Subject: Re: [Exist-development] Moving towards a new API

Hi,

JSR 225 was the "XQuery API for Java (XQJ)" project. 
http://www.jcp.org/en/jsr/detail?id=225

I looked at it a couple months ago and thought it was mostly too much 
like JDBC to be a useful XMLDB-API replacement.

I really do like the XMLDB-API's approach, especially because it works 
both remote and local. If it was a tad more up-to-date -- e.g. more like 
the fluent API it'd be even better!



Eugene (an exist-devel lurker)


On 9/3/2010 10:38 PM, Jason Smith wrote:
> We talked on Thursday about a new API that would be more powerful than existing APIs and provide a wrapper for the internal API.
>
> After thinking about this some more, I'd like to consider the XMLDB-API model.  There is a lot that is right about the XMLDB wrapper.  It has pretty good collection and resource facilities, and it can be used to access large data sets in a "sequence"-like manner.
>
> I think where XMLDB falls down is around standardization.  The XMLDB standard was designed in the days when an XML database could do XPath 1.0.  It can't fully support the XQuery standard without significant changes.  It can't be extended to do some of the things that eXist does specifically.  XMLDB as a standard seems kind of dead at this point anyway.
>
> Just one example - this email is getting too long...  I can't use XMLDB to return a Sequence of xs:dateTime, which I then pass as a parameter to another XQuery.  XMLDB only deals with string output, and the set of input types is very limited.
>
>
>
> So right now, I am thinking about an API that would aspire to replace the XMLDB API in Exist.  I think it should also hide (wrap) the current locking and transaction mechanisms (since these are bound to change in the next year or two).
>
> It would not be based on any standard, but would be designed to provide maximally simple and powerful access to as much of the internal API as possible, and to be easy to extend as new features become available.
>
> If we do it right, we could also make this a cross-platform API (supporting languages other than Java), kind of like the REST API today, but targeted to language APIs.
>
> Does this sound like a good path to start down?  Different ideas?
>
> BTW, I know there is a JSR that covers an XML database API somewhere out there, or one was in work...  I looked at it a long time ago, and it did not seem all that applicable.  Is there any interest in that API, and if so, can someone point me to a link?  I seem to be having trouble finding it again.
>
> Thanks!
>
> -Jason S.
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development