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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
