Rokham Sadeghnezhadfard wrote: > Hi, > > I have the following questions: > > 1. Does Jackrabbit guarantee unique IDs to nodes which are not in the > same workspace? This could be something we definitely want down the > road in order to be able to share resources? Not exactly.
Jackrabbits (really JCRs) concept of a workspace is really based around versioning. Workspaces are like branches or tags in CVS or Subversion. So an entire workspace can be "copied", to another workspace which would be a like creating a branch or tag. Then changes can be synchronized between the 2 workspaces. So because of this there can be nodes with the same id in 2 workspaces. However in this case this is really supposed to be the same node just 2 versions of that node. But if you create a new node in a workspace or repository it is intended to be unique. That is the nature of UUIDs. http://en.wikipedia.org/wiki/UUID Whenever a new one is created it is supposed to be unique from all other ones that are created. This is typically done by using the computer network MAC address plus a time code plus some random data. Workspaces don't have to be used this way. They can be seen as top level divisions of the repository, but the JCR API does provide all the methods for synchronizing 2 workspaces based on a shared version history. > > 2. We need to keep some structure for storing images/documents and > other sorts of resources. This is because when a new ELO is created > and its resources are passed to the CMS layer, we need to know where > we're putting the resources. This is very trivial but we need to come > up with a structure. Also this could become slightly tricky because > the otml file needs to also know which version of the resource they're > interested in. Project A can want the first version of an image and > project B would want version 5. Also we need to take care of the > deletion impacts on resources. What happens to the resource when > project B is deleted? The issue of handling deletion is typically based on containment. If Project B contains the resource then it will be deleted when Project B is deleted. In JCR terms if the resource is a child node of Project B then then the resource will be deleted. However JCR also can check for referential integrity. So if Project A references a resource contained by Project B. Then Project B cannot be deleted until that reference is broken. Using these techniques it is possible to check if any resources contained by Project B are referenced outside of project B. And then at least a message can be displayed to someone doing the deletion. Or the resource can be moved to a shared location before project B is deleted. Or some other policy can be devised for handling this case. Versioning individual resources will be tricky. It is difficult to maintain version specific references to individual resources. We talked about this a Sail retreat a couple of years ago. My opinion was to use a concept identical to JCR's workspace approach. So with in a particular workspace only one version of a resource (node) can be referenced. If 2 versions of the resource need to be referenced within the same workspace then a copy of the resource has to be made. > > 3. Overall given all the involved parties are happy with the > otml/otrunk infrastructure, I don't know if we need the new system > YET. It's possible that the concord team needs this enhancement for > some of their other projects but I don't know. Please let us know if > that's the case Scott/Aaron/Stephen. I'm not completely sure which enhancement your are referring to. If it is the original email by Carlos, then no I don't think we need it. However if that is data model for the ELO API then I think we can support that API or the original data model. Scott > > > ps. Turadg as to your questions below: > METADATA and CONTENT are children of the ELO name node. Do they have > any siblings or will they? > > From what I know/remember METADATA and CONTENT do NOT have any siblings. > > That's my two cents. > > On Sat, May 24, 2008 at 6:38 PM, Turadg <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > Sounds like a reasonable approach. I have some clarification > questions. > > You say that "metadata is stored in the otmlMetadata node". I assume > that's just for OTML files? A JPEG would have a different node under > METADATA? > > METADATA and CONTENT are children of the ELO name node. Do they have > any siblings or will they? > > Why is there a contentFile node within CONTENT? Why not just put the > content on the CONTENT node. Am I missing something? > > > On May 22, 9:40 pm, "Carlos Celorrio" <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Hi everybody, > > > > We've been thinking of ways of integrating Scott's code and > ideas for the OT > > representation > (http://confluence.concord.org/display/CSP/OTrunk+Jackrabbit) in > Roolo. > > > > Currently, the structure for the ELOs in Roolo inside Jackrabbit is > > > > a-b-c > > |-METADATA > > | |-otmlMetadata > > |-CONTENT > > |-contentFile > > > > a-b-c is an ELO with content and metadata. The metadata is > stored in the > > otmlMetadata node. > > > > Scott's idea is about having scattered ids inside the otml file > so that can > > act as anchors for referencing them from inside the otmlFile or > externally. > > We think that's something very powerful, but we also want to > provide a > > general way in roolo for other contents (Images, PDFs, Word files, > > whatever...) that do not have an xml structure. We have come up > with a new > > jackrabbit internal representation for the objects that admit a > structured > > content (xml file) as well as raw data (images...). > > > > |-Photo * > > | > > |-Document ** > > | > > |-AirbagProject *** > > | |-root > > | |-bundles > > | | |- ... > > | |-Children > > ... > > > > * is an Image file ELO, ** is a PDF file ELO, *** AirbagProject > is an OTML > > file ELO > > Metadata is stored in *, ** and *** nodes, but as AirbagProject > is an > > structured ELO, it has structure and possibly ids and more > metadata inside > > to be able to reference its parts. > > > > Thoughts about it? > > > > Geoff, Tony and Carlos > > > > > -- > Rokham > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SAIL-Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/SAIL-Dev?hl=en -~----------~----~----~----~------~----~------~--~---
