In order to decrease the load on the database and heap from large attachments, I would like to propose a filesystem based storage mechanism. I propose the addition of 2 interfaces for storing large binary content, a database table to track the files on the filesystem, a new configuration parameter for the location of persistent filesystem storage, and an implementation of each interface. The reason for writing an abstract binary storage interface rather than a new implementation of AttachmentStore, AttachmentVersioningStore, and AttachmentRecycleBinStore is that the code would be duplicated or should I say triplicated. BinaryStore will provide a means for not only storage of attachments but storage of other large items which we may decide we want in the future. I plan to keep the current implementations of AttachmentStore, AttachmentVersioningStore and AttachmentRecycleBinStore intact so it will be the user's choice how they store attachments. interface com.xpn.xwiki.store.BinaryStore will contain: @param toLoad a binary object with an id number set, will be loaded. void loadObject(BinaryObject toLoad) @param toStore a binary object, if no id is present then it will be given one upon successful store, if id is present then that id number will be used. void storeObject(BinaryObject toStore) This will be implemented by: com.xpn.xwiki.store.hibernate.HibernateBinaryStore com.xpn.xwiki.doc.BinaryObject would contain: void addContent(InputStream content) OutputStream addContent() void clear() InputStream getContent() void getContent(OutputStream writeTo) clear() would clear the underlying file whereas addContent would always append to it. The added column would look like this: <class name="com.xpn.xwiki.store.doc.FilesystemBinaryObject" table="filesystembinaryobject"> <id name="id" column="id"> <generator class="native" /> </id> <property name="fileURI" type="string"> <column name="fileuri" length="255" not-null="true"/> </property> </class> WDYT? Caleb