Marek, Yes I thought about windows shares. On the internet (as opposed to intranet) the word "security" leapt to mind and I went away from the idea. Has anyone used Samba shares on the internet or know if its secure/insecure?
Thanks Chris Marek Kilimajer wrote: > The only way I see this can be done is simly let every user mount a > share under the same letter, > all you need to do then is <a > href="file:///X:/directory/file.doc">file</a>, then locking files is up > to samba or windows server. > > Marek > > Richard Lynch wrote: > >>> I have an intranet, which provides access to, amongst others, Word >>> Documents about policies, etc. What the guys are looking for is a >>> way to do the following: >>> >>> 1. Show a list of files available for editing >>> 2. If a file is clicked, then it is locked for other users (no access) >>> 3. The file opens on the client's machine >>> 4. The client edits it >>> 5. The client then closes the file, it "auto-saves" and he goes >>> about his business. >>> >>> Points 1 through 3 are relatively trivial. Point 4 and 5 (especially >>> 5) have me lost. >>> >>> How do you get a file to be edited, and then automatically returned >>> to the server by M$ Word in it's changed format. Is this possible? >>> >>> How would this change in a database-backended system (including the >>> files as BLOBs)? >>> >> >> >> They'd have to be "uploaded" *SOMEHOW*... >> >> If the employees can't do that "by hand", then perhaps some kind of >> "scheduled" task on the Win boxes could be programmed to do it. >> >> Don't forget to *UNLOCK* after a successful upload, but not when, not >> if, >> when, the upload fails. >> >> There's simply NO WAY the server can reach out and suck in a file of >> its own >> volitoin... Major privacy/security problem there. >> >> You *COULD* also install Apache + PHP on every desktop, and have them >> serving up their edited Word files to the Intranet, and then PHP >> could use >> HTTP to suck them back in... >> >> But that's probably not gonna fly for non-technical reasons. Well, not >> counting really bad Security as a "technical" reason. >> >> >> > > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
