jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: Jackrabbit Transactions [former: Adding WebDAV to Jackrabbit]
Date Mon, 01 Nov 2004 14:01:50 GMT
> That's Slide's special feature. You can map all kinds of stores to
> resource paths. You can even do this with different aspects of a
> resource. E.g. you can store all content of resources in a folder to
> the file system and all the meta data into an RDBMS. All other paths
> could well be mapped to be help in memory only (just as an example).
> Now it should be obvious that all stores need to participate in the
> global tx as a resource might affect all stores. They  do so by
> implemention XAResource.
hmmm... while i appreciate a feature of virtualizing multiple
datasources in a single tree,
i would still question an architecture where a repository has
to ship its own tm. if the slide tm is a good general purpose
tm, then i would suggest that you talk to the geronimo
guys since they probably should be interested, or am i 
way off here?

> WebDAV and the client library and WebDAV JCA implementation for Slide
> is like JDBC and SQL for RDBMS.
> Using the client Side JCA implementation you can have both a local and
> a distributed transaction.
a comparison that involves proprietary and standardized apis, a 
protocol and a querylanguage makes my head spin ;)

> As a side note if anyone asks I always recommend not to 
> use Slide's native API, but to go the "SQL and JDBC" way. 
> This even makes your implementaion independent of Slide 
> and you could *theoretically*  - just like with SQL and 
> JDBC ;) - exchange Slide with another WebDAV server - 
> like SVN for example - which people seem to experiment 
> with already.
i think to use webdav as a protocol to remote
a "content repository api" is a very good idea, that we already 
discussed with remy (& others) about 2 years ago.
[ also see a couple of post earlier on this list ]
i think we additionally benefit from the fact that we do not 
remote a proprietary api but one that is specified through a jsr,
which means that the application developer is not just 
independant from the server implementation but
also from the transport protocol between the client and 
the server (just like with jdbc, to put that in the correct perspective).

or to unspin my head, we can maybe agree to to something like that:
jdbc is for rdbms, what jcr is for content repositories.

> As explained above this is the way it works. Each store implements
> XAResources and is enlisted in the global transaction.
> > to me the slide transactions look like they are not really
> > jta, but just somehow use some jta interfaces in a
> > questionable way. but again my apologies, i might be
> > completely wrong here.
> No need for apologies, but it seems to me you are wrong here...
to me, the way how the repository chooses to interact
with its stores, does not have to be exposed to the 
repository user (developer). i understand that for 
people that develop stores this is very interesting.
however i think for the vast majority of content 
repository application developer should not develop 
stores, much like the j2ee devs should not develop
for example jms provider components.

again, thank you very much for the 
interesting discussions, i think this certainly
helps me to learn a lot about slide.


View raw message