Repository for nomades ?

[Hervé Agnoux]

Hi,

I have some users which are on or offline, on a PC or another. They read or
write JCR Repositories.

Is there some way to synchronize repository, commit changes when off -> on
line, and so on ?

Thank you for your help.

[Michael Wechner]

Hervé Agnoux schrieb:
> Hi,
>
> I have some users which are on or offline, on a PC or another. They read or
> write JCR Repositories.
>
> Is there some way to synchronize repository, commit changes when off -> on
> line, and so on ?
>  

you mean similar to SVN/Subversion?

Cheers

Michael
> Thank you for your help.
>
>  

[Hervé Agnoux]

Le mercredi 08 juillet 2009, Michael Wechner a écrit :

> Hervé Agnoux schrieb:
> > Hi,
> >
> > I have some users which are on or offline, on a PC or another. They read
> > or write JCR Repositories.
> >
> > Is there some way to synchronize repository, commit changes when off ->
> > on line, and so on ?
>
> you mean similar to SVN/Subversion?
>

No, excuse my english.

Some use case.

I mean when a user work on a software offline. So the soft use a local JCR.
When he goes online, the local JCR need to populate a central JCR, on a
server.  

Or, when a person works with a computer, and then with an other, she want to
transfert its JCR from the first post to the second.

Or, when two persons work together, with their own JCR, they wants, sometime,
synchronize their JCR Repository.

Is there some utilities in jackarabbit to do that ?

Thanks.

[Alexander Klimetschek]

2009/7/9 Hervé Agnoux <[hidden email]>:

> I mean when a user work on a software offline. So the soft use a local JCR.
> When he goes online, the local JCR need to populate a central JCR, on a
> server.
>
> Or, when a person works with a computer, and then with an other, she want to
> transfert its JCR from the first post to the second.
>
> Or, when two persons work together, with their own JCR, they wants, sometime,
> synchronize their JCR Repository.
>
> Is there some utilities in jackarabbit to do that ?

No and I haven't heard of someone doing such a synchronization so far.
But contributions are welcome ;-)

Depending on how much of JCR you want to support (and if you want
synchronization in both directions), this can be quite an effort. But
if you only want to copy content in one direction, this is simpler -
you "just" need a transport format (we have packaging in our
commercial JCR implementation, Day CRX [1]).

[1] http://www.day.com/crx

Regards,
Alex

--
Alexander Klimetschek
[hidden email]

[Hervé Agnoux]

Le jeudi 09 juillet 2009, Alexander Klimetschek a écrit :
>
> No and I haven't heard of someone doing such a synchronization so far.
> But contributions are welcome ;-)
>

Hum... if there is no code, are there some framework or good practice for that
?

[Alexander Klimetschek]

2009/7/9 Hervé Agnoux <[hidden email]>:
> Le jeudi 09 juillet 2009, Alexander Klimetschek a écrit :
>>
>> No and I haven't heard of someone doing such a synchronization so far.
>> But contributions are welcome ;-)
>>
>
> Hum... if there is no code, are there some framework or good practice for that?

Well, subversion or git come to my mind ;-) But they don't allow for
fine-grained properties, fulltext search, simple API, etc., all the
goodies from JCR. I also don't know if there are similar things
available in the relational database world.

I agree that such a framework would be really cool. Maybe it could be
more easily implemented if one creates a special persistence manager
that runs for the user workspaces on the central server and actually
fetches the data from the client, where another, local persistence
manager access the same data. Upon sync, the local one would have to
be temporarily stopped, the one on the server is started, accesses the
data remotely and then the JCR workspace merge operations are used to
sync the data. (Maybe the persistence managers have to be the other
way around, ie. the remote pm is actually running on the client side,
which works better in terms of routers/firewalls).

Clustering, btw, is not an option, since a cluster node could be
disconnected from the cluster while the rest of the cluster continues
to work, but then it is not running at all, ie. you could write
anything locally if there is no access to the cluster's global
journal. And it would depend on the persistence managers clustering
abilities as well.

Regards,
Alex

--
Alexander Klimetschek
[hidden email]

[Alexander Klimetschek]

On Thu, Jul 9, 2009 at 2:27 PM, Alexander Klimetschek<[hidden email]> wrote:
> but then it is not running at all, ie. you could write
> anything locally if there is no access to the cluster's global
> journal.

Of course I meant "but then it is not running at all, ie. you could
*not* write anything locally if there is no access to the cluster's
global journal".

Regards,
Alex

--
Alexander Klimetschek
[hidden email]

[Hervé Agnoux]

Le jeudi 09 juillet 2009, Alexander Klimetschek a écrit :

>
> I agree that such a framework would be really cool. Maybe it could be
> more easily implemented if one creates a special persistence manager
> that runs for the user workspaces on the central server and actually
> fetches the data from the client, where another, local persistence
> manager access the same data. Upon sync, the local one would have to
> be temporarily stopped, the one on the server is started, accesses the
> data remotely and then the JCR workspace merge operations are used to
> sync the data. (Maybe the persistence managers have to be the other
> way around, ie. the remote pm is actually running on the client side,
> which works better in terms of routers/firewalls).
>

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 ?

Also, I need something like a journal, to register the changes offline. 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 ?

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

mmmm...... very interesting.

[Alexander Klimetschek]

2009/7/9 Hervé Agnoux <[hidden email]>:
> 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:
http://www.day.com/specs/jcr/1.0/8.2.10_Merge.html

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
http://www.day.com/specs/jcr/1.0/7.1.8.2_Update.html

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

Regards,
Alex

--
Alexander Klimetschek
[hidden email]

[Hervé Agnoux]

Le jeudi 09 juillet 2009, Alexander Klimetschek a écrit :

>
> 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:
> http://www.day.com/specs/jcr/1.0/8.2.10_Merge.html
>
> 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
> http://www.day.com/specs/jcr/1.0/7.1.8.2_Update.html
>

I'm going to try in these directions. Thanks.

[Alexander Klimetschek]

2009/7/9 Hervé Agnoux <[hidden email]>:
> I'm going to try in these directions. Thanks.

Let us know if you make any progress, this could be something for the
Jackrabbit Sandbox ;-)

http://svn.apache.org/repos/asf/jackrabbit/sandbox/

Regards,
Alex

--
Alexander Klimetschek
[hidden email]

[Hervé Agnoux]

Le vendredi 10 juillet 2009, Alexander Klimetschek a écrit :

> 2009/7/9 Hervé Agnoux <[hidden email]>:
> > I'm going to try in these directions. Thanks.
>
> Let us know if you make any progress, this could be something for the
> Jackrabbit Sandbox ;-)
>
> http://svn.apache.org/repos/asf/jackrabbit/sandbox/
>
> Regards,
> Alex

I think it's a long time job... I have begun.

I don't understand very well the idea of "merge". I work with the idea of the
decorator pattern.

A myself-repository wraps the real repository, and distrib the call first to
the real, second to the distant (a mirror, or a synchro, or any other thing).

It's only the idea ! For the implementation, I have make only two or three
methods. For the distant repository, I have made a little "rest" web app.

Do you think it's a good direction ?

And I don't know how to do the tests. Is there some facilities to test a
repository in jackrabbit or jcr ?

Thanks for the help.

[Alexander Klimetschek]

2009/7/17 Hervé Agnoux <[hidden email]>:
> I don't understand very well the idea of "merge". I work with the idea of the
> decorator pattern.
>
> A myself-repository wraps the real repository, and distrib the call first to
> the real, second to the distant (a mirror, or a synchro, or any other thing).

But in this case you need the remote connection available when the
client writes data - in which case you always require a network
connection and could just access the remote repository directly.

Also it wouldn't be faster (one could say it's a slow connection, the
local save is then faster), because if you wrap the JCR API used by
the client, the calls would need to block until all parts (local and
remote) are finished, to ensure proper behaviour.

There is no way around using a merge in this situation ;-) The good
thing about the merge is, that the hard part of merging is mostly
implemented in Jackrabbit already and that the spec is very clear
about it.

> And I don't know how to do the tests. Is there some facilities to test a
> repository in jackrabbit or jcr ?

Assuming you want to test the JCR API, of course there are tests, as
Jackrabbit is the reference implementation for the JCR spec, hence
contains the whole test suite.

For Jackrabbit 1.5, based on JCR 1.0:

http://svn.apache.org/repos/asf/jackrabbit/branches/1.5/jackrabbit-jcr-tests/

For the upcoming Jackrabbit 2.0, with the JCR 2.0 API as basis:

http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-jcr-tests/

Regards,
Alex

--
Alexander Klimetschek
[hidden email]