On 5/12/08, Paul Noden <[EMAIL PROTECTED]> wrote: > Ok, i need to learn some of these acronyms pretty quick! iiirgs? > > So I think you're suggesting that the work should continue with the > json strategy (downplaying the idea of large scale tasks) whilst you > ensure the sysview becomes exposed in some suitable way? yes, as long the JSON format that is already defined for default rendering is not altered.
-- toby > > > Paul > > > On 5/11/08, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > > > > > > > > > > > > > > > >
