Jim
----- Original Message ----- From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, October 05, 2004 6:24 AM
Subject: RE: Initializing files at startup
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]
