jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: Repository for nomades ?
Date Thu, 09 Jul 2009 19:06:39 GMT
2009/7/9 Hervé Agnoux <herve.agnoux@diaam-informatique.com>:
> Yes, I see something like that.
> I look at Sling, but I don't see any dialog between some temporaries
> repository and a central one, or some concepts like that.
> Do you know if sling is a good approche, or if it is better to start with
> JackrabbitRepositoryServlet ?

Sling is very good for the webapplication part on top of a JCR. I
think the sync issue is totally orthogonal to what Sling does; you'd
use for easy rendering of content and implement the sync part on the
repository layer.

> Also, I need something like a journal, to register the changes offline.

No, because if you use the workspace merging capabilities built into
JCR/Jackrabbit, you don't have to do that. The way the algorithm works
is clearly specified in section 8.2.10 of the JCR spec:

This requires the presence of the versioning storage, but this could
be on the server and would only be used upon sync... or at least I
think so. Clients would only work on the node and never call any
versioning operations. Only during sync, when all workspaces incl. the
versioning are present, it should be accessed.

Otherwise, there is still the "simpler" Node.update which basically
just copies the latest state of a node from another workspace, so this
would only be a one-direction copy instead of a full sync; see

> I have
> seen something like that in jackrabbit with clusters. I understand that
> clusters is not a good approch, but do you think only the journal is
> intersting ?

As noted before, the cluster and its journal do not help here. They do
not allow for a full sync and the journal itself only contains the
list of changed revisions, not the actual data of a revsion.

> And also something like a proxy repository, or a mirror repository, I suppose.

Proxy repository sounds like using the JCR API on both ends of the
proxy + a "built-in" delay? This is the big effort I talked about in
my first reply, because implementing and supporting the full JCR API
for such a proxy/cache/delay is actually quite difficult. Though you
could reduce it to simple read and write operations and ignore things
like search, versioning, transactions, nodetypes etc.


Alexander Klimetschek

View raw message