Re: [xwiki-users] Applications: MultiPage Export, Recruitment, Todo Macro

Thank you for these apps! Ludovic Dubost Since the apps now appear to all be serialized wiki-documents saved with extension ".xml" in subversion, what about having a simple app-installer which avoids the entire XAR process and allows more fine-grained subversion updating of apps. In other words, as both the application "code" and "document" reside in subversion, installing a new Xwiki app would be as simple as loading a single-document containing "meta" information about the app like it's subversion repo URL, app name&description, and a manifest listing any files that need saving with special permissions. The app would then consult the subversion URL and reconstruct documents in the appropriate space(s) and permissions (per manifest). E.g. documents for the "recruitment" app would be build directly from these: - Loading.xml<http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwik… - Settings.xml<http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwi… - WebHome.xml<http://svn.xwiki.org/svnroot/xwiki/sandbox/applications/xwik… - CandidateClass.xml<http://svn.xwiki.org/svnroot/xwiki/sandbox/applicatio… - CandidateClassSheet.xml<http://svn.xwiki.org/svnroot/xwiki/sandbox/appli… - CandidateClassTemplate.xml<http://svn.xwiki.org/svnroot/xwiki/sandbox/ap… - ... Eventually,such a mechanism could entail some form of dependency-control on updating apps, e.g. app-branches for different underlying xwiki versions; when you upgrade to a new version of xwiki, any apps installed this way would automatically update changed documents to their new version. Of course, application authors would want to be able to "go the other way", saving out whole spaces/collections of documents into an external subversion repository... The app would, in groovy, via HTTP, read each subversion document into a "pipe", capturing a single document as XML "in memory" (groovy->java) and write it to the database with set-content and save/save-with-prog-rights Xwiki API's. As this would be done one XML file at a time, the maximum "memory explosion" would be the size of the largest XML document (e.g. translations doc) in the app, as opposed to the current situation. (Seems like it would be easier to sidestep large xar export/import issues this way, rather than trying to make XAR import export work via streaming). And of course, if you ended up customizing an application-document on your server, subversion would be used to merge any non-conflicting upgrades to the document that might occur as the application is improved.... Niels http://nielsmayer.com