Jim, sounds very good what you are describing. I'm not sure if I can distinguish between "DBinitialization" and "serverStartup" within the repository initialization mechanism I'm slightly extending (common/XMLUNmarshaller.java), as it uses Slide Core API and is independent from the underlying store or database.
Regards, Peter > -----Original Message----- > From: Jim Myers [mailto:[EMAIL PROTECTED] > Sent: Freitag, 1. Oktober 2004 19:12 > To: Slide Developers Mailing List > Subject: Re: Initializing files at startup > > I think this is VERY useful functionality. We have similar > use cases and developed similar capabilities (combined with > some other modifications that has slowed us in getting it in > shape to send back to Slide). Users have asked for two types > of things: > > Bulk import of files when starting a fresh server: for > example, we distribute an electronic notebook that runs on > top of our modified Slide server and we want to upload all > the images and other files it uses the first time the server runs. > > Synch of files from a local dir into the repository at each > startup or on > demand: we have people using our server as a store for a > portal and they drop configuration files and other resources > in. Whenever they change their configuration, they'd like to > redeploy their portal related files and have the Slide > repository suck in the new files. > > To support these, we first added a content node in Domain.xml > for single files (or expanded - I think Slide 1 had some > limited content mechanism didn't it?) and then decided to > create a second recursive bulk directory upload mechanism > (for any top level children of the specified dir, upload from > the recursively if the corresponding node doesn't exist in > the repository - that is - upload when the db is created and > whenever the admins delete the node in the repository). We > also experimented with an overwrite flag for things in > Domain.xml - overwrite="yes" implies the node or property is > reset to the value in Domain.xml at each server start. > > So - I think your mechanisms 2) and 3) below are the most > relevant for us and some "uploadAt" flag that can be set to > "DBinitialization" or "serverStartup" (default is at > DBinitialization and the flag can be applied to properties > and/or content... :-) would cover a lot of ground. > > Daniel's comment about an archive mechanism sounds like a > separate useful feature. We have lots of people who put > content in and worry that if useful information is put in the > properties, they'll lose it all if they decide to go back to > a file system instead of webDAV. A nice XML export format > that could gather one or more resources and their properties > would solve this, as well as allowing for bulk transfer > between repositories. > > Jim > > > > > ----- Original Message ----- > From: "Stefan L�tzkendorf" <[EMAIL PROTECTED]> > To: "Slide Developers Mailing List" <[EMAIL PROTECTED]> > Sent: Friday, October 01, 2004 11:16 AM > Subject: Re: Initializing files at startup > > > > Hallo Peter, > > installing a webdav server with some inital template data would be > > intresting in some of our projects too. > > > > One query I have is, what happens if the server starts up a second > > time and the content of the file or the referenced collection is > > changed? Is it updated, are new subdirectories added or how do you > > handle this? > > > > Regards, Stefan > > > > > > > > [EMAIL PROTECTED] wrote: > > > >> Hi, > >> > >> to initialize data in a repository during server start-up, > I can add > >> <objectnode> elements in Domain.xml. For instance, I could add an > >> element <objectnode classname="..." uri=/files/foo"/> > inside <objectnode > >> classname="..." uri=/files"/> to have a folder > "/files/foo" initialized. > >> Also, to an <objectnode> element, I could add a <revision> element > >> containing <property> elements in order to initialize > properties. All > >> this is *not* new. But, what I *cannot* do, so far, is to > initialize > >> content of files. And > >> that is precisely what one of my customers using Tamino > WebDAV Server > >> (TWS) would like to do. He wants to install a WebDAV > repository with > >> certain initial content, but he doesn't want the > installation procedure > >> to require a running server for doing the initialization. > Also, doing > >> the initialization in the underlying database is not a good idea > >> (because must know schema of the metadata). > >> > >> So, yesterday, I invented a new <content> element which I > can add to > >> <revision> elements in order to initialize content. This > can be done in > >> 3 ways, as shown in the following examples: 1) The initial > content of > >> /files/sample.xml is specified directly in > >> Domain.xml: > >> > >> <objectnode > classname="org.apache.slide.structure.SubjectNode" > >> uri="/files"> > >> <objectnode > classname="org.apache.slide.structure.SubjectNode" > >> uri="/files/sample.xml"> > >> <revision> > >> <content><![CDATA[<sequence>tralala</sequence>]]></content> > >> </revision> > >> </objectnode> > >> </objectnode> > >> > >> 2) The initial content of /files/sample.xml is taken from the file > >> referenced to by the 'file' attribute of the <content> element: > >> > >> <objectnode > classname="org.apache.slide.structure.SubjectNode" > >> uri="/files"> > >> <objectnode > classname="org.apache.slide.structure.SubjectNode" > >> uri="/files/sample.xml"> > >> <revision> > >> <content file="../etc/init_data/sample.xml"/> > >> </revision> > >> </objectnode> > >> </objectnode> > >> > >> 3) The initial content of the /files directory is taken > from the folder > >> referenced to by the 'dir' attribute of the <content> > element (and it > >> can be a whole structure of folders and files): > >> > >> <objectnode > classname="org.apache.slide.structure.SubjectNode" > >> uri="/files"> > >> <revision> > >> <content dir="../etc/init_data"/> > >> </revision> > >> </objectnode> > >> > >> As my customer's TWS is based on Slide 2.0, I coded this > feature into my > >> local copy of the SLIDE_2_0_RELEASE_BRANCH and it works > quite good so > >> far (see attached .diff file). > >> > >> My questions: > >> - what do you think about this feature? > >> - ideas how to improve it? > >> - shall I check-in and also merge into SLIDE_2_1_RELEASE_BRANCH? (I > >> think it is a low impact add-on) > >> > >> Thanks in advance! > >> > >> Regards, > >> Peter > >> > >> > >> > >> > >> > >> > -------------------------------------------------------------- > ---------- > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > > Stefan L�tzkendorf -- [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
