28 Jan
2011
28 Jan
'11
5:33 p.m.
I would like to move the attachment storage code into the trunk for testing and inclusion
in 3.0.
I would like to put it in /core/xwiki-store/ which can begin the modularization of the
storage engine.
The filesystem attachment storage is still a work in progress but the main attachment
storage class
runs. I have added a new type of lock which automatically breaks deadlock and might solve
the
problem with deletion sometimes blocking.
This code depends on and includes:
TransactionRunnable which will allow us to evaluate TR in real life situations.
Serialization apis for including a refactoring of the existing XMLWriter.
File save/delete TransactionRunnables which serve as primitives for safe file saving and
deletion on
the filesystem.
Lock manager which is still brand new and has to be moved into it's own package yet.
An EntityReferenceSerializer for getting file paths from document names.
This code provides:
FilesystemAttachmentStore which is beta and functional.
FilesystemAttachmentVersioningStore which is alpha and "you're on your
own".
along with compatible FilesystemAttachmentContent and ListAttachmentArchive.
Here is my +1 for including this in the core so it can be developed and tested in
concert.
Caleb
29 Jan
29 Jan
2:08 p.m.
On Jan 28, 2011, at 5:33 PM, Caleb James DeLisle wrote:
I would like to move the attachment storage code into
the trunk for testing and inclusion in 3.0.
I would like to put it in /core/xwiki-store/ which can begin the modularization of the
storage engine.
The filesystem attachment storage is still a work in progress but the main attachment
storage class
runs. I have added a new type of lock which automatically breaks deadlock and might solve
the
problem with deletion sometimes blocking.
This code depends on and includes:
TransactionRunnable which will allow us to evaluate TR in real life situations.
Serialization apis for including a refactoring of the existing XMLWriter.
File save/delete TransactionRunnables which serve as primitives for safe file saving and
deletion on
the filesystem.
Lock manager which is still brand new and has to be moved into it's own package yet.
An EntityReferenceSerializer for getting file paths from document names.
This code provides:
FilesystemAttachmentStore which is beta and functional.
FilesystemAttachmentVersioningStore which is alpha and "you're on your
own".
along with compatible FilesystemAttachmentContent and ListAttachmentArchive.
Here is my +1 for including this in the core so it can be developed and tested in
concert.
+1
Thanks
-Vincent
31 Jan
31 Jan
5:25 p.m.
+1, I'd like to test it as well.
Guillaume
On Sat, Jan 29, 2011 at 14:08, Vincent Massol <vincent(a)massol.net> wrote:
On Jan 28, 2011, at 5:33 PM, Caleb James DeLisle wrote:
I would like to move the attachment storage code
into the trunk for
testing and inclusion in 3.0.
I would like to put it in /core/xwiki-store/
which can begin the
modularization of the storage engine.
The filesystem attachment storage is still a work in progress but the
main
attachment storage class
runs. I have added a new type of lock which
automatically breaks deadlock
and might solve the
problem with deletion sometimes blocking.
This code depends on and includes:
TransactionRunnable which will allow us to evaluate TR in real life
situations.
Serialization apis for including a refactoring of
the existing XMLWriter.
File save/delete TransactionRunnables which serve as primitives for safe
file
saving and deletion on
the filesystem.
Lock manager which is still brand new and has to be moved into it's own
package yet.
An EntityReferenceSerializer for getting file
paths from document names.
This code provides:
FilesystemAttachmentStore which is beta and functional.
FilesystemAttachmentVersioningStore which is alpha and "you're on your
own".
along with compatible FilesystemAttachmentContent
and
ListAttachmentArchive.
Here is my +1 for including this in the core so it can be developed and
tested in
concert.
+1
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1 Feb
1 Feb
2:08 a.m.
New subject: [xwiki-devs] [VOTE] Move filesystem attachment storage into the core.
On 01/28/2011 05:33 PM, Caleb James DeLisle wrote:
I would like to move the attachment storage code into
the trunk for testing and inclusion in 3.0.
I would like to put it in /core/xwiki-store/ which can begin the modularization of the
storage engine.
The filesystem attachment storage is still a work in progress but the main attachment
storage class
runs. I have added a new type of lock which automatically breaks deadlock and might solve
the
problem with deletion sometimes blocking.
This code depends on and includes:
TransactionRunnable which will allow us to evaluate TR in real life situations.
Serialization apis for including a refactoring of the existing XMLWriter.
File save/delete TransactionRunnables which serve as primitives for safe file saving and
deletion on
the filesystem.
Lock manager which is still brand new and has to be moved into it's own package yet.
An EntityReferenceSerializer for getting file paths from document names.
This code provides:
FilesystemAttachmentStore which is beta and functional.
FilesystemAttachmentVersioningStore which is alpha and "you're on your
own".
along with compatible FilesystemAttachmentContent and ListAttachmentArchive.
Here is my +1 for including this in the core so it can be developed and tested in
concert.
+1 for the idea, I'll look at the code to verify it's OK soon.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
7:41 a.m.
New subject: [xwiki-devs] [VOTE] Move filesystem attachment storage into the core.
+0
Thanks,
Marius
On 01/28/2011 06:33 PM, Caleb James DeLisle wrote:
I would like to move the attachment storage code into
the trunk for testing and inclusion in 3.0.
I would like to put it in /core/xwiki-store/ which can begin the modularization of the
storage engine.
The filesystem attachment storage is still a work in progress but the main attachment
storage class
runs. I have added a new type of lock which automatically breaks deadlock and might solve
the
problem with deletion sometimes blocking.
This code depends on and includes:
TransactionRunnable which will allow us to evaluate TR in real life situations.
Serialization apis for including a refactoring of the existing XMLWriter.
File save/delete TransactionRunnables which serve as primitives for safe file saving and
deletion on
the filesystem.
Lock manager which is still brand new and has to be moved into it's own package yet.
An EntityReferenceSerializer for getting file paths from document names.
This code provides:
FilesystemAttachmentStore which is beta and functional.
FilesystemAttachmentVersioningStore which is alpha and "you're on your
own".
along with compatible FilesystemAttachmentContent and ListAttachmentArchive.
Here is my +1 for including this in the core so it can be developed and tested in
concert.
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:05 p.m.
+1
On Fri, Jan 28, 2011 at 17:33, Caleb James DeLisle
<calebdelisle(a)lavabit.com> wrote:
I would like to move the attachment storage code into
the trunk for testing and inclusion in 3.0.
I would like to put it in /core/xwiki-store/ which can begin the modularization of the
storage engine.
The filesystem attachment storage is still a work in progress but the main attachment
storage class
runs. I have added a new type of lock which automatically breaks deadlock and might solve
the
problem with deletion sometimes blocking.
This code depends on and includes:
TransactionRunnable which will allow us to evaluate TR in real life situations.
Serialization apis for including a refactoring of the existing XMLWriter.
File save/delete TransactionRunnables which serve as primitives for safe file saving and
deletion on
the filesystem.
Lock manager which is still brand new and has to be moved into it's own package yet.
An EntityReferenceSerializer for getting file paths from document names.
This code provides:
FilesystemAttachmentStore which is beta and functional.
FilesystemAttachmentVersioningStore which is alpha and "you're on your
own".
along with compatible FilesystemAttachmentContent and ListAttachmentArchive.
Here is my +1 for including this in the core so it can be developed and tested in
concert.
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
1:48 p.m.
New subject: [xwiki-devs] [VOTE] Move filesystem attachment storage into the core.
My +1.
paul
Le 28 janv. 2011 à 17:33, Caleb James DeLisle a écrit :
I would like to move the attachment storage code into
the trunk for testing and inclusion in 3.0.
I would like to put it in /core/xwiki-store/ which can begin the modularization of the
storage engine.
The filesystem attachment storage is still a work in progress but the main attachment
storage class
runs. I have added a new type of lock which automatically breaks deadlock and might solve
the
problem with deletion sometimes blocking.
This code depends on and includes:
TransactionRunnable which will allow us to evaluate TR in real life situations.
Serialization apis for including a refactoring of the existing XMLWriter.
File save/delete TransactionRunnables which serve as primitives for safe file saving and
deletion on
the filesystem.
Lock manager which is still brand new and has to be moved into it's own package yet.
An EntityReferenceSerializer for getting file paths from document names.
This code provides:
FilesystemAttachmentStore which is beta and functional.
FilesystemAttachmentVersioningStore which is alpha and "you're on your
own".
along with compatible FilesystemAttachmentContent and ListAttachmentArchive.
Here is my +1 for including this in the core so it can be developed and tested in
concert.
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5072
days inactive
5076
days old
6 comments
7 participants
participants (7)
-
Caleb James DeLisle -
Guillaume Lerouge -
Marius Dumitru Florea -
Paul Libbrecht -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol