16 Dec
2008
16 Dec
'08
4:47 p.m.
Vincent Massol wrote:
On Dec 16, 2008, at 10:50 AM, Eduard Moraru wrote:
[snip]
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/
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.