Yes, please!! This is what I had in mind for a longer time, but never managed to start working on it: A WebDAV-client-tool that determines the server capabilities by doing some OPTIONS request and retrieves the content by doing the appropriate WebDAV-requests afterwards. This would have the big advantage that it works with different WebDAV-based repositories and works if different Slide instances use different storage configurations. It might be a bit tricky to retrieve not only the content but also properties, locks, acl and versioning information, but it finally would be the most elegant solution. If we find a good XML representation for content/properties etc. we could use this for data import as well. The xml-format could consist of nested elements representing each resource. This would enable to "dump" the repository located under a given path and import it to a different location. Optional flags could be used to ignore locks/acl/versioning information. Just a dream... or is someone interested in implementing this? As stated before I had this on my personal roadmap for a while but am very busy at the moment and can hardly find the time to do it.
Cheers, Daniel "Slide Users Mailing List" <[EMAIL PROTECTED]> schrieb am 24.11.04 23:04:34: > > It sounds like writing a client tool to migrate content from one Slide > server to another one might be a good option. This should be fairly > simple to write using the Webdav client library. Another option that I > originally had in mind is to simply perform a database dump on the > staging server and upload this to production. Of course, this would > preserve the entire version history, which we most likely won't care > about on our production server, so a separate tool might be more > appropriate. > > -Mirko > > > On Wed, 2004-11-24 at 13:58, Richard Emberson wrote: > > > I must preface my remarks by stating that our Slide deployment will use > > a database for storage. > > > > Consider Slide namespaces. From what I've heard and based upon the > > mailing list traffic, multi Slide namespace installations do not > > occur very often. Lets say that such installations work just fine, > > - each namespace could use a different database - > > one would need some external Slide/webdav tool/script to promote > > (copy) directories from dev namespace to test namespace to production > > namespace. > > Since one has to create and use such a promotion tool, its not clear > > that having a single Slide with three namespaces buys one anything > > over having three distinct Slides each with their own DB. > > I am assuming that to promote a directory involves getting it (the > > whole directory hierarchy) into the (client) tool from one Slide > > server and then putting into a second Slide server. > > This is true even if one has the three Slide databases on the same > > database server; one must extract the directory from one db and > > insert it into another. > > > > Our dev Slide server will be version controlled while the test and > > production need only have non-versionable copies. > > > > > > Mirko Froehlich wrote: > > > Our current staging environment really serves a different purpose. Our > > > test, staging, and production servers correspond to phases in our > > > software development cycle and are strictly separated. We definitely > > > wouldn't want to use the production Slide server for development or test > > > purposes, so those at the minimum would need to be separate servers. > > > However, my example of publishing web content from staging to production > > > uses a different concept of staging than we currently have, so it may > > > not be an ideal example. I suppose for this scenario the content could > > > very well live in two different folders on the production Slide server, > > > with a simple publishing process that copies or moves content from the > > > staging to the production server. I guess in the end this really depends > > > on the workflows we need. For example, for content updates on the live > > > site this approach would probably work well. But lets say we develop a > > > new major version of the application with significant changes to our web > > > content management framework and corresponding new content in the > > > repository. When this goes live, we would need to publish the content > > > from the staging Slide server to the production server. > > > > > > I know this is somewhat hypothetical at this point. I'm just trying to > > > get a feel for how people use Slide. Yours is definitely a viable > > > option. > > > > > > -Mirko > > > > > > > > > On Wed, 2004-11-24 at 12:58, Richard Emberson wrote: > > > > > > > > >>For my information, why would you not have top-level directories: > > >>dev, staging, and production; all within the same Slide server? > > >> > > >>Richard > > >> > > >> > > >> > > >>Mirko Froehlich wrote: > > >> > > >>>Those of you who are using Slide in a production environment, what kind > > >>>of publishing workflow have you put in place? > > >>> > > >>>We will likely end up using Slide for various aspects of our > > >>>application. Initially, it will mostly serve as a repository for > > >>>user-specific application data. In this scenario, the user data would > > >>>only live on the production server and there would not have to be a > > >>>publishing process that moves data from staging to production. However, > > >>>there's a good chance that we may end up using Slide for web publishing > > >>>as well, in which case we would probably want to be able to manage > > >>>content on the staging server and push it to production as part of a > > >>>publishing workflow. > > >>> > > >>>I suppose this could be as simple as performing a database dump on > > >>>staging and loading it on production. We would probably set up multiple > > >>>db stores, which would allow us to publish the part of the repository > > >>>that is used for web publishing, but not the part of the repository that > > >>>contains the users' application data. > > >>> > > >>>Anyway, I would be interested in hearing about your experiences and best > > >>>practices that you have determined for these kinds of scenarios. > > >>> > > >>>-Mirko > > >>> > > >>> > > >> > > > > > > ________________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
