On 5/11/08, Paul Noden <[EMAIL PROTECTED]> wrote: > 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? what do you mean by jcr console? there is a sling console that provides administrative tasks on the osgi level.
> 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 think that creating/modifying a subtree within 1 request is a valid and useful operation, and we should add it to the default post servlet. especially because the default GET servlet already offers a JSON serialization of partial or entire node trees. for 'real' export/imports that also are repository independent, i would still use sysview, since the (current) JSON format lacks information like namespaces and property types. and i frankly don't know, how this could be (nicely) added to the JSON format. one advantage of using the post servlet with and adapted sysview or another format like JSON is that binaries could be included in separate multi-parts and don't need to be character encoded using base64 or friends. > 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. IMO these are 2 different things. large import/export is rather a bootstrapping, migration or backup/restore task. if the application uses launchpad or not is more or less a configuration or deployment option. > 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? sure. for example an application that "imports" some external data, like newsfeeds or documents, etc into the repository, this can be highly adapted to the needs and capabilities of the respective client. > 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. there are 3 UUID collision behaviors defined: 1) error 2) create new 3) replace where 1) throws an error when a referenceable node is imported that already exists in the repository. 2) a new UUID is created and all references from within the imported data are adjusted and 3) existing content is replaced by the one that is imported. > 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? this should not be too difficult since it's basically an API call on the jcr level. but i would also add support for importing a JSON serialized content, such as the default GET servlet generates. AFAIK this is already done by the bundle-resource loader. so that code could be shared. as i said earlier, we could (if possible) add support for "contentids" for binary properties that can reference data from other multiparts or support base64 encoded binaries in the JSON format (iiirgs :-). -- regards, toby > 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 > > > > > > > > > >
