Re: My Slide store implementation experience
Ty C wrote: Greetings! I have implemented a store that implements all of Service, ContentStore, LockStore, NodeStore, RevisionDescriptorsStore, RevisionDescriptorStore, SecurityStore. I would like to share my impressions of the task I undertook with both the Slide developers and the wider Slide development audience. I would also like to ask some philosophical questions. First of all, I decided to use Tomcat + Slide as I want to build upon the (hard) work of others. Some of the Slide-specific advantages I see are: 1. The task of understanding, assimilation, and implementation of WebDAV (and the peculiarities of the clients) is handled by experts external to my organization 2. WebDAV and its brethren are, to varying degrees, moving targets (see 1 above) 3. The software license and open source license terms are very agreeable :) 4. As a member of the Apache group, the software is more inclined to use other Apache libraries, happily coincidental to my own employment of the same libraries. Next I solicited advice on a starting point from this mailing list. Using the 2.0 beta 1 source code as a starting point, the wonderfully helpful responders suggested I look at the StandardRDBMSAdapter and the TxFileContentStore. The high-level interface was clear to me, the division of responsibility explicit. Even without many comments, I found both the DB adapter and file system content source code to be didactic at a a high-level. Some of the points of difficulty I encountered are: 1. I could not rapidly understand the data structures, such as NodeRevisionDescriptors, due to my not finding related documentation. I hopefully figured out what was needed to run my store implementation in the general cases by observing parameter values in Eclipse during Slides initialization phase and from Slide querying my store. 2. In some cases, strictly in terms of programming to an interface, I ignored parameters at times (and I am still unclear if this is the correct behavior) for methods such as the ObjectNode. parameter of the ObjectNode.removeObject(). I am not sure what the intention of the developers are in these cases; what are they communicating by including parameters like these? 3. Had I some externalized material that allowed me to comprehend Slides various objects (such as more graphs and/or documentation on the developers website) such as data structures I would have finished much faster. If this were the case, the barrier to adoption of Slide as a front-end is lowered. I feel that if you take care of the developers, they will take care of you; this may or may not apply to the Slide project. But my point is this: If the organization wants to further the uptake of Slide, make it easier for developers to develop for Slide :) As a developer who went through the experience I would like to suggest that the following will make my life easier: 1. Document how to write a Store (thoroughness about the interface would be most appreciated!) The thing that makes Java so easy to develop with is that the class libraries that come with the JRE (and JDK) are very well documented. Hi, it would be great if you could write a small tutorial or something like that as you already discovered the areas of slide that needs to be touched when implementing a store. Keep in mind that the original developers didn't comment their code well and it's a hard task to get this done and cleaned up sometimes. So any help is very (very) welcome! 2. Document the data structures! In fact, I would very much appreciate calling a method with a descriptive identifier instead of figuring out that I have to put a (String, NodeRevisionNumber) into a Hashtable of latestRevisionNumbers. You are absolutely right, but: changing interfaces is not a good idea as many stores or other applications that we don't even knwo rely on them. 3. This may come as a surprise: If there was a high-level interface that abstracted WebDAV with more raw operations, such as MOVE and MAKECOL, I would have preferred to write to that interface. As I am implementing a versioning filesystem, I had difficulty with the translation from PUT MAKECOL into NodeStore.createObject() ContentStore.createRevisionContent() in terms of knowing what was a file and what was a directory. I implemented this first creating object nodes as 0 length files in our document management system backend. Once I received a request to create an object as a child of this object, I transformed the 0 length file into a folder and then created the sub-child as a 0 length file.. Is there a better way? It's sad but true: The interfaces don't reflect the webdav layer well at the moment. If you create a new revision using the slide api you can't access this revision via deltaV-calls. So there is a lot to do in this area (cleaning up interfaces and extend them so that they can be used to integrate e.g. subversion as a store). Personally I think this should be one
Re: My Slide store implementation experience
Yes, please send copy to me also, if possible. I'd like to get my feet wet here. We also would like to look at writing a versioning system with slide/webdav layer above. Or at least understand how to display previous versions to users, that may already be stored in the history area. [EMAIL PROTECTED] 5/7/2004 4:50:20 PM Ty C wrote: As a developer who went through the experience I would like to suggest that the following will make my life easier: 1. Document how to write a Store (thoroughness about the interface would be most appreciated!) The thing that makes Java so easy to develop with is that the class libraries that come with the JRE (and JDK) are very well documented. 2. Document the data structures! In fact, I would very much appreciate calling a method with a descriptive identifier instead of figuring out that I have to put a (String, NodeRevisionNumber) into a Hashtable of latestRevisionNumbers. 3. This may come as a surprise: If there was a high-level interface that abstracted WebDAV with more raw operations, such as MOVE and MAKECOL, I would have preferred to write to that interface. As I am implementing a versioning filesystem, I had difficulty with the translation from PUT MAKECOL into NodeStore.createObject() ContentStore.createRevisionContent() in terms of knowing what was a file and what was a directory. I implemented this first creating object nodes as 0 length files in our document management system backend. Once I received a request to create an object as a child of this object, I transformed the 0 length file into a folder and then created the sub-child as a 0 length file.. Is there a better way? +1 on the above list! I'd love to use Slide for the WebDAV layer talking to my own store, but my last two efforts stranded in lack of time as I was trying to reverse-engineer the existing stores to extract the specs from them. Ty, if your store isn't too complex, I'd love to have a peek to see if I could use it as a starter for my own. Emile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Postmaster made the following annotations. -- This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Slide store implementation experience
Ty C wrote: As a developer who went through the experience I would like to suggest that the following will make my life easier: 1. Document how to write a Store (thoroughness about the interface would be most appreciated!) The thing that makes Java so easy to develop with is that the class libraries that come with the JRE (and JDK) are very well documented. 2. Document the data structures! In fact, I would very much appreciate calling a method with a descriptive identifier instead of figuring out that I have to put a (String, NodeRevisionNumber) into a Hashtable of latestRevisionNumbers. 3. This may come as a surprise: If there was a high-level interface that abstracted WebDAV with more raw operations, such as MOVE and MAKECOL, I would have preferred to write to that interface. As I am implementing a versioning filesystem, I had difficulty with the translation from PUT MAKECOL into NodeStore.createObject() ContentStore.createRevisionContent() in terms of knowing what was a file and what was a directory. I implemented this first creating object nodes as 0 length files in our document management system backend. Once I received a request to create an object as a child of this object, I transformed the 0 length file into a folder and then created the sub-child as a 0 length file.. Is there a better way? +1 on the above list! I'd love to use Slide for the WebDAV layer talking to my own store, but my last two efforts stranded in lack of time as I was trying to reverse-engineer the existing stores to extract the specs from them. Ty, if your store isn't too complex, I'd love to have a peek to see if I could use it as a starter for my own. Emile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
My Slide store implementation experience
Greetings! I have implemented a store that implements all of Service, ContentStore, LockStore, NodeStore, RevisionDescriptorsStore, RevisionDescriptorStore, SecurityStore. I would like to share my impressions of the task I undertook with both the Slide developers and the wider Slide development audience. I would also like to ask some philosophical questions. First of all, I decided to use Tomcat + Slide as I want to build upon the (hard) work of others. Some of the Slide-specific advantages I see are: 1. The task of understanding, assimilation, and implementation of WebDAV (and the peculiarities of the clients) is handled by experts external to my organization 2. WebDAV and its brethren are, to varying degrees, moving targets (see 1 above) 3. The software license and open source license terms are very agreeable :) 4. As a member of the Apache group, the software is more inclined to use other Apache libraries, happily coincidental to my own employment of the same libraries. Next I solicited advice on a starting point from this mailing list. Using the 2.0 beta 1 source code as a starting point, the wonderfully helpful responders suggested I look at the StandardRDBMSAdapter and the TxFileContentStore. The high-level interface was clear to me, the division of responsibility explicit. Even without many comments, I found both the DB adapter and file system content source code to be didactic at a a high-level. Some of the points of difficulty I encountered are: 1. I could not rapidly understand the data structures, such as NodeRevisionDescriptors, due to my not finding related documentation. I hopefully figured out what was needed to run my store implementation in the general cases by observing parameter values in Eclipse during Slides initialization phase and from Slide querying my store. 2. In some cases, strictly in terms of programming to an interface, I ignored parameters at times (and I am still unclear if this is the correct behavior) for methods such as the ObjectNode. parameter of the ObjectNode.removeObject(). I am not sure what the intention of the developers are in these cases; what are they communicating by including parameters like these? 3. Had I some externalized material that allowed me to comprehend Slides various objects (such as more graphs and/or documentation on the developers website) such as data structures I would have finished much faster. If this were the case, the barrier to adoption of Slide as a front-end is lowered. I feel that if you take care of the developers, they will take care of you; this may or may not apply to the Slide project. But my point is this: If the organization wants to further the uptake of Slide, make it easier for developers to develop for Slide :) As a developer who went through the experience I would like to suggest that the following will make my life easier: 1. Document how to write a Store (thoroughness about the interface would be most appreciated!) The thing that makes Java so easy to develop with is that the class libraries that come with the JRE (and JDK) are very well documented. 2. Document the data structures! In fact, I would very much appreciate calling a method with a descriptive identifier instead of figuring out that I have to put a (String, NodeRevisionNumber) into a Hashtable of latestRevisionNumbers. 3. This may come as a surprise: If there was a high-level interface that abstracted WebDAV with more raw operations, such as MOVE and MAKECOL, I would have preferred to write to that interface. As I am implementing a versioning filesystem, I had difficulty with the translation from PUT MAKECOL into NodeStore.createObject() ContentStore.createRevisionContent() in terms of knowing what was a file and what was a directory. I implemented this first creating object nodes as 0 length files in our document management system backend. Once I received a request to create an object as a child of this object, I transformed the 0 length file into a folder and then created the sub-child as a 0 length file.. Is there a better way? All in all, thank you for your continued effort! Ty C Lingo Systems Inc.
