On 5/10/08, Paul Noden <[EMAIL PROTECTED]> wrote: > Some interesting points, the main focus of this work is a restful > mechanism which is available within the sling launchpad. The code > could be switched to another format once time has been spent reviewing > the strategy but JSON offers expedience right now due to the existing > mechanisms and I wonder if it is perhaps not more in line with the > restful strategy? why would that be? JSON is not more restful than XML or XYZ - it's not the data transport format that makes a protocol restful but rather the single command/response handling and the resource addressing. IIRC one of slings primary ideas is to implement a framework for a JCR repository, so it should reuse and cultivate the principles of JCR.
> Hopefully this work will trigger us to think about > how sling projects will want to work with importing and exporting > content and initiate a discussion? WDYT? i think import/export is more of an administrative task that is not used every day. an import could have loads of content and could take a couple of hours to complete. and certainly one would not send gigabytes of import data via an HTTP post. since the JCR api already offers specified mechanisms of import/export, applications should use them, and not a YAI/EM. > Felix is planning to translate the output of this work into the work > he is doing on SLING-422, so I hadn't been aware of the full scope of > those changes. But this actually answers my question on passing > additional parameters to define the operation. > > I should have a svn patch available sometime early next week. i'll be happy to take a look at it. -- regards, toby > On 5/9/08, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > > On 5/9/08, Paul Noden <[EMAIL PROTECTED]> wrote: > >> The Import/Export round-trip is something that's critical once > >> projects start to migrate or backup content, so I'm working on > >> introducing a mechanism for importing content on the sling level. > >> Script import/export is available using the webdav interface and > >> doesn't need any special support, and we already have a suitable > >> content export model - JSON. A suggestion from Felix was to introduce > >> a :import post parameter which would take the JSON file as a direct > >> input. The filename itself is irrelevant, and it's content should > >> always be JSON. > > my first question is: why introducing a new import/export format when > > JCR already defines the sysview XML for exact that purpose? > > furthermore, the API provides methods for exporting and importing. > > > >> The import assumes create and overwrite but not delete so the > >> following would recreate the contents of /content, leaving nodes not > >> in the file untouched. > >> curl -F":[EMAIL PROTECTED]" http://admin:[EMAIL PROTECTED]:8888/content > >> > >> I've written the import method to be performed last in the stack of > >> operations - the post method allows us to send multiple operations, so > >> the following would delete the existing content and then import the > >> content from the file. > >> curl -F":delete=/content" -F":[EMAIL PROTECTED]" > >> http://admin:[EMAIL PROTECTED]:8888/content > > please note, that the multi-commands will be removed shortly. see > > https://issues.apache.org/jira/browse/SLING-422 for details. > > > >> In addition to your thoughts on the above, I would like suggestions on > >> the simplest method for only importing new/deleted nodes - does it > >> really require an additional flag/operation? > >> > >> WDYT on introducing the new operation to the sling client library? > >> Would we want to introduce a content import form to allow a GUI > >> approach to Import/Export? Probably through the creation of a simple > >> admin bundle? > >> > >> The work seems most likely be contained entirely within the > >> SlingPostProcessor and SlingPostServlet objects, and am working on it > >> at the moment. > > > > i think it could be an added value to add support for importing > > sysview serializations via the default PostServlet. but then the > > default GET servlet should also be able to produce sysview exports > > (don't know if this is already implemented). > > > > -- > > regards, toby > > >
