Hi Caleb,
I haven't looked at the code yet but could you provide the architectural vision going
forward and how this module would relate to the future storage module. Also imagining we
use JCR as the storage engine and/or API, how would this module integrate with it?
Thanks
-Vincent
On Oct 28, 2010, at 1:45 PM, Caleb James DeLisle wrote:
In light of the need for better attachment handling, I
spent the past few days working on the basic
framework for a new module to support large objects. The code can be viewed here:
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-blob/src/main/java…
Use case #1: Multiple methods of storing content and the ability to define more.
Use case #2: Thread safe locking to prevent concurrent modifications from damaging
content.
Use case #3: ACID commit/rollback protection.
The API user has 2 access points.
BinaryObject is a thread safe interface with ACID and option of using OutputStream or
InputStream to
set and get data.
StorageItem is a simplistic interface modeled after a small subset of the methods in
java.io.File.
If you create a component which implements StorageItem, BinaryObjectProvider will allow
you to
access a BinaryObject which uses your StorageItem for persistent storage.
Example:
@Requirement
private BinaryObjectProvider provider;
private BinaryObject binaryObj;
public void initialize()
{
this.binaryObj = this.provider.get("myImpl");
}
"myImpl" is the hint for the StorageItem which you may define.
The next step is of course to add versioning support but I think this will provide a
solid
foundation to build that on.
WDYT?
Caleb