>From my conversation with Felix on the import it appears to be the case, and I don't understand why, that the jcr console isn't made available when using the default launchpad? Can someone let me know either where or why this is?
When I considered the restful strategy of an import operation it was with the potential producers and consumers also in mind- specifically the extra work that a javascript client would have to do. This is a small subset of the use case for a system import operation, so forgive and ignore me. I'd imagine large sling projects wouldn't utilise the default configuration of launchpad, for the very issues toby described regarding large amounts of data.They would have a much greater need to configure and access the repository directly, so projects should avoid transferring excessive amounts of data across http if adopting a recommended architecture. Assuming a transitory mechanism is available to get projects between architectures these assumptions might be fairly realistic? The sysview export comes with a lot more data than the abstracted sling related content, can sysview be safely imported into a different location from where it was exported- for example to duplicate content or recreate it under a different path? That is to say without concern for duplicate UIDs or incorrect/broken references? Given the use on the JCR level I assume it's safe. I think this work has great importance to working with sling and I would be very happy to collaborate with toby on making a sysview import/export available if this is best? Paul. On 5/10/08, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > 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 > > > > > >
