27 Jan
2011
27 Jan
'11
1:26 p.m.
Hi Caleb,
Thanks for the detailed information.
So if my count is ok there's work left for a minimum of 21 men/days to finish it. We
have 6 days till 3.0M2, 10 more for RC1 and 10 more for final, so a total of 26 days.
However if we want to include it in 3.0 final (and we do want this since it's in our
roadmap :)), I suggest that you'd need to have something usable (with known
issues/limitations) in XE 3.0M2, planned for the 7th of February 2011. Is that doable on
your side? The idea is to let users start using it and provide feedback and find potential
issues which we could fix in 3.0 RC1 and RC2.
I'm also +1 to move your work in platform ASAP (you need to start an official vote for
this in a separate thread). Could you explain where it would go? Would you suggest to have
it all go in platform/core/xwiki-store module? Does it have deps on the old xwiki-core?
Thanks
-Vincent
On Jan 26, 2011, at 6:59 PM, Caleb James DeLisle wrote:
Hello,
Here's an update on the current state of new filesystem attachment storage:
There are a couple platforms on which attachment storage sits:
* Transaction handling - This is finished to my satisfaction. We may decide later that it
is
inadequate or needs changing but it serves this purpose now.
* Transaction safe file save/delete - Finished (based on transaction handling)
* Serialization - Finished refactoring of XMLWriter and generic Serializer and
XMLSerializer.
* Providing of files - Mostly finished, needs review to see if there is a cleaner way.
Barring any
major changes, this should not take longer than 1 day to complete.
* Locking - Needed, lock management exists but does not handle deadlock nor "greedy
thread"
situations. 3 days needed to do code review on Apache commons LockManager to determine if
it handles
these situations, I'm guessing 2 days are needed to integrate LockManager and in
place of the
existing lock mechanism and a further 3 days to implement one of the features on top of
LockManager
if need be.
"Consumer" code:
* FilesystemAttachmentStore - Complete, enabling requires adding the .jar file to WEB-INF
and
changing a line in xwiki.cfg. Suffers from deadlock because the locking mechanism, is
inadequate.
* FilesystemAttachmentVersioningStore - Complete but needs tests, enabling is same as
for
FilesystemAttachmentStore. 1-2 days should be adequate for testing.
* FilesystemAttachmentRecycleBinStore - in progress, 3 days to complete and test (?).
Finished
DeletedFilesystemAttachment, need TransactionRunnables for saving and deleting and
serializer for
deleted attachment meta-data.
* Need a plan for migrating data from old system. FilesystemAttachmentStore fails over to
old store
if an attachment cannot be found. Is this correct? Should migration scripts be
distributed instead?
WDYT?
* Consumer code all needs more tests. Any amount of time could be spent on this, I think
a week is
adequate.
Since this contains a large amount of code and all storage code is critical, I think this
should go
through a release cycle in the platform but disabled by default so that it can be beta
tested before
it becomes official. WDYT?
Caleb