On Thu, 2008-09-18 at 23:31 +0200, André Warnier wrote:
> Martin Spinassi wrote:
> [...]
> 
> Martin,
> 
> I re-read the thread from the beginning, and as I understand it you have 
> - clients that upload files, most of then images
> - clients that download these same images
> - and you would like a system that handles this and duplicates the 
> images to 2 or more "synchronised" places, so as to have redundancy and 
> backup.
> 
> Let me describe a part of an application which I designed, and see if 
> this inspires you.  This was under Apache, but it should be possible 
> also under Tomcat.
> 
> I wanted to provide clients with a hierarchical folder hierarchy where 
> they could upload their documents via a simple drag and drop, but I did 
> not want to have to scan the whole structure regularly to check if 
> anything had been uploaded there.
> Plus, I wanted to know who uploaded what when, and wanted to do 
> something to those files after they uploaded them.
> Plus, I am lazy and not such a big-shot programmer, so if something 
> already exists and works well, I prefer to use it than to re-develop my 
> own buggy version.
> 
> At the core, for allowing clients to upload the (in my case) documents, 
> there is DAV (which is also implemented under Tomcat).
> DAV, allows the client to see a folder structure on the server, and 
> drag-drop files in it, just like to a remote network drive. It even 
> works in Windows with the Explorer (not IE, the other one), it's called 
> "web folders" there.
> But once the file is dropped somewhere, you don't know anymore who put 
> it there.  Plus, since they can drop a file anywhere in the folder 
> hierarchy, you have to explore the whole hierarchy regularly on the 
> server to find the files they've dropped, if any.
> 
> Except that, at the base, DAV is just an HTTP protocol extension. It 
> makes requests through URLs, and such requests get processed by a HTTP 
> server.  The requests just use different "command verbs" than GET and 
> POST.  For a while, I was thinking of creating my own handlers for those 
> verbs (PUT, MKCOL, OPTONS,..), or taking the DAV code, and implement my 
> own additional desired functionality into it.
> Then I realised that DAV being a HTTP protocol extension, you can do 
> HTTP authentication, and you can use filters around it.  That's true in 
> Apache, and also in Tomcat.
> 
> So let's say that when a user wants to drop a file via DAV, you 
> intercept the HTTP requests, authenticate the request, and save that 
> somewhere.
> Next, your filter gets to run. It sees where the user is going to drop 
> the file (the URL of the PUT), and remembers it.  Then it lets the 
> request go through DAV (the actual file upload into a folder somewhere), 
> DAB being the filtered application here. Then when the DAV response 
> comes back through the filter, the filter takes the uploaded file from 
> where it is now (it knows the exact folder), and copies it to another 
> place (or does whatever you want with it). In addition, the filter also 
> knows who did it and other details, so it can pass this information 
> somewhere to be saved (into a database record ?).
> 
> I personally find this more elegant than
> a) re-inventing the wheel : to upload/download files from a HTTP server, 
> is something for which DAV was designed, and the developer spent a lot 
> of time making it work reliably
> b) triggering external syncs in real-time
> 3) scanning the file structure later to sync
> 
> DAV also allows drag-and-drop downloads, and they also go through HTTP 
> requests...
> 
> You don't need to change DAV in any way, you just "wrap" it in filters 
> that do what you want around it.
> 
> André


André, first of all, thank you very much to take the time to re-read the
thread and write such a good response, I really appreciate it.


About DAV, it looks like you really made something big there.
I don't know if it applies to my case (or if I have the chance to do
it). 
The site I'm trying to make is some kind of a forum/social web. People
make threads or posts, and add it some pictures to illustrate it.

My first shot was rsync, just in case that one tomcat suddenly dies, the
other one would have almost all the pictures. NFS can be a better
option, and have a daily reply in one tomcat box, just in case the nfs
server stop working.


Once again, thanks for your response and time. I don't know how to apply
it here, but it surely is a must read, I'll give a try to the DAV
documentation.


Cheers



Martín


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to