Vincent Massol wrote: > On Dec 16, 2008, at 10:50 AM, Eduard Moraru wrote: > > [snip] > >> P.S.: From what I asked around, it seems that attachments are not >> objects. That seems weird to me because, intuitively, the attachments >> should be objects on a page of the class Attachment. On attachments >> you >> have versioning, meta-data and an attachment can exist on a page or >> not, >> the behaviour of an object. Could anybody explain the reason for this >> please? > > > I think I agree (need to think more of consequences). Probably > historical reason. Attachments have a separate store but we could > generalize this to let objects have an optional separate store too.
The problem is that we don't have property types suited for storing attachments. The largest one is TextArea, which can hold 60k, not enough for most attachments. Other problems are: - Different storage for attachments, as they tend to be quite big. Storing objects on the filesystem is not good, since we need to query objects, something not easy (or efficient) to do on the FS. - Users should not be able to edit attachments using the object editor, since most attachments are binary. - Harder to track the history of objects, and we need to display attachments' history. - Harder to ensure that no 2 objects with the same filename are specified. - Lucene plugin has to be adapted a lot - Lots of API breakage -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
