I see. this is still far away from decision but in my own opinion: 1. Document content should be in a separate file where it is easily accessible, the file extension would probably have to be standardized to something like .xwiki2 2. document content, metadata and objects should all be integrated in the same directory structure. This will allow for easy storage, backup, and define an alternative and more robust import/export format.
Caleb On 01/26/2011 03:37 PM, Paul Libbrecht wrote: > Caleb, > > > My question below was about the page content. > (in the future it might apply to several other fields of objects, such as > panel source). > > paul > > > Le 26 janv. 2011 à 21:21, Caleb James DeLisle a écrit : > >> >> >> On 01/26/2011 02:10 PM, Paul Libbrecht wrote: >>> >>> Le 26 janv. 2011 à 18:59, Caleb James DeLisle a écrit : >>> >>>> Hello, >>>> Here's an update on the current state of new filesystem attachment storage: >>> >>> This is real cool. >>> >>>> [...] >>> >>>> * Serialization - Finished refactoring of XMLWriter and generic Serializer >>>> and XMLSerializer. >>> >>> Is this actually exporting the content in a separate file? And is the >>> extension of this file somewhat configurable (at least .grv, .html, or .vm) >>> ? The XML deserialization would then use XInclude. >>> The interest is that it would allow back-end changes and/or svn commits and >>> updates in a way that is compatible with IDEs. >> >> Yes, the attachment content goes into a file named whatever the attachment >> is named. >> It will be something like this: >> <storage dir>/xwiki/Sandbox/Test/~this/attachments/file.txt/file.txt >> The metadata such as date, uploader, and version will be made into an XML >> file by the serializer. >> That will look something like this: >> <?xml version="1.0" encoding="UTF-8"?> >> <attachment serializer="attachment-meta/1.0"> >> <filename>file1</filename> >> <filesize>10</filesize> >> <author>me</author> >> <version>1.1</version> >> <comment>something whitty</comment> >> <date>1293045632168</date> >> </attachment> >> >> serializer="attachment-meta/1.0" >> That is the component lookup name of the serializer which makes way for >> future xml serializer >> implementations. >> >> Versions of the file will be in the same directory: >> The naming rule is as follows: >> The filename is URL encoded and the version has "~v" prepended so that it >> cannot be >> mistaken for part of the filename. >> If the filename contains one or more '.' characters then the version is >> inserted before >> the last '.' character. Otherwise it is appended to the file name. >> This means a file such as: >> file.txt version 1.1 will become file~v1.1.txt and will still be recognized >> by a text editor >> A file with no extension such as myUnknownFile version 1.1 will become >> myUnknownFile~v1.1 >> Because of URL encoding, a file named file~v1.3.txt of version 1.1 will >> become >> file%7Ev1.3~1.1.txt and thus will not collide with file.txt version 1.1. >> >> Caleb >> >>> >>>> [...] >>>> 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? >>> >>> To me this sounds like the best approach. >>> >>> paul >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
