2009/7/9 Hervé Agnoux <[email protected]>: > 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 [email protected]
