Squirrel wrote: >> On Sat, Mar 29, 2008 at 4:48 PM, [Ricardo Rodriguez] Your EPEC Network ICT >> Team <[EMAIL PROTECTED]> wrote: >> Well, obviously I am not a XWiki guru, but it seems to me that it was, >> and in fact it is, a good idea to have a single access control system. >> If you have the whole system in a database, you have not to be concerned >> about how to control access to other repositories. And at at the same >> time, to have the whole thing in a single database gives, at least to >> me, an feeling of full control about what is going on with the contents >> I've to manage. Other idea: you easy can index and search the whole >> content with a single search engine. And control access to the results! >> >> But, as you says, there are a number of problems with this approach. >> >> I am sure this thread will be useful for you... >> >> >> http://www.nabble.com/Xwiki-file-and-attachment-storage-td11991466.html#a11991466 >> >> And as a last minute entry, see this... >> >> http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebDAVApi2008 >> >> Hope this helps, >> >> Ricardo >> > > Pardon me to raise my hand again, but I still don't get it after reading it > over and over again. This JackRabbit-Implementation, will it allow to store > files in the file-system rather than in the DB? What about, ie., the > photo-album feature, will it still work when the fotos are stored in the > file-system?
The storage consists of several interfaces, like XWikiStoreInterface, XWikiAttachmentStoreInterface, XWikiVersioningStoreInterface and others. The data model is an abstract data structure that can be accessed, and where exactly it is stored is of no importance. The storage interfaces can have any implementation, it could even be a plain filesystem storage (though it would be hard to do search that way...). Now, the JCR storage adds an extra abstraction layer. It is meant to be a generic storage interface which can have many implementations, and it actually does have those implementations. The advantage of using JCR is that we're dropping the implementation concern to a third party, instead of having to write it ourselves. JCR can be configured to use the filesystem as the storage component, so, up the library chain, the attachments will be: - stored on the filesystem (JCR storage implementation) - transparently transformed to a storage service available using a JCR API (JCR core) - retrieved from there... (XWiki Storage Interface) - ...and transformed into a data model object (XWikiAttachment) - and then used however you want in the core, web, or document content So, given the abstraction layer behind the data model, anything should work as normal regardless of where are attachments really stored. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
