Come utilizzare DAV
L'accesso tramite DAV è consentito solo tramite protocollo https ( accesso crittografato ). L'indirizzo a cui fare riferimento è quindi https://<il.tuo.dominio>/dav
Ecco alcune risorse per DAV
Questa è una funzionalità molto potente che permette di visualizzare i file e cartelle remote come direttamente fruibili sul vostro computer.
è accessibile tramite cadaver (applicazione tipo ftp a terminale) oppure tramite gnome dalla versione 2 come cartella remota
Windows (a partire da Internet Explorer 5.0)
Apri esplora risorse, seleziona dal menu file l'opzione Apri file e, nella finestra che si apre seleziona il checkbox (cartella web)
Se questo non funziona allora vai su Risorse di rete, seleziona strumenti -> connetti unità di rete e segui le istruzione per "cartella web"
Una alternativa rimane sempre cadaver http://soren.lund.org/cadaver.html
Mac OS X
Mac OS X 10.3 (Panther) and earlier Using WebDAV to upload and access files in Mac OS X 10.3 (Panther) and earlier requires a third-party client called Goliath http://www.webdav.org/goliath/ . Note: Goliath has some known performance issues, and may not work 100% of the time. Because of this, only limited support is available if you experience problems.
- Mac OS X 10.4 (Tiger) To use WebDAV to upload and access files in Mac OS X 10.4 (Tiger), follow these steps: In the Finder, press Cmd-k . (Alternatively, from the Go menu, choose Connect to Server.)
Per altri software puoi vedere a:
Alcune importanti note le trovi qui ( in inglese )
Q. Why should I use DAV instead of FTP?
A: Since DAV works over HTTP, you get all the benefits of HTTP that FTP cannot provide. For example: strong authentication, encryption, proxy support, and caching. It is true that you can get some of this through SSH, but the HTTP infrastructure is much more widely deployed than SSH. Further, SSH does not have the wide complement of tools, development libraries, and applications that HTTP does.
DAV transfers (well, HTTP transfers) are also more efficient than FTP. You can pipeline multiple transfers through a single TCP connection, whereas FTP requires a new connection for each file transferred (plus the control connection).
Q. Can non-DAV applications be converted to use DAV?
A: major feature of DAV is that it provides an upward migration path for existing non-collaborative applications which operate on entire files. WebDAV has been designed so that existing applications can easily add WebDAV support, since locks apply to entire resources, and the namespace operations support "File... Open" and "File... Save" user interfaces. DAV client APIs are lightweight, and hence do not add a significant development burden. The applications in Office 2000 are the first non-collaborative applications to be DAV-enabled, and others will surely follow. As applications transition to adding DAV support, existing applications can be used on the local filesystem, and a program like sitecopy can upload changed files to a DAV server for you. Microsoft is also providing a feature called "Web folders" which makes a collection on a DAV server appear to be a directory in Windows. Non-DAV applications cannot work with these folders because the files/folders are only an appearance -- they are not mapped into a local filesystem. A Windows "redirector" could be written to make them appear as a local filesystem, but until that time, applications will need to be changed to work with a DAV-enabled server.
Q: Which major vendors/products are actively involved with DAV?
A: While the IETF expects that all participants are individual contributors, a lot can be learned by looking at the corporate affiliations of key participants. After all, if they're able to spend significant time developing DAV, they probably have the full support of their organization. Participants from Microsoft, Netscape, Novell, and Xerox spent significant time developing the base DAV protocol, and there was significant interest by participants from document management vendors such as Filenet, Documentum and PC Docs as well. Jim Whitehead from U.C. Irvine chaired the effort, which is significant when you realize his officemate is Roy Fielding, a founder of the Apache Group. Combined, these organizations have the ability to make DAV a de-facto standard, with combined controlling marketshare on both the client and server side.
A: team with world-class versioning and CM expertise is working to develop the versioning standard. Participants on the design team come from Rational (Clear Case), Microsoft (Visual Source Safe), Intersolv (PVCS), Novell (Group Wise), and IBM (Envy), and there are academic participants from U.C. Irvine and Boston University. These people have the experience to develop a good standard, and come from organizations with sufficient market share to make this a de-facto standard. These organizations also have significant experience and marketshare in software development tools. However, it is important to know that the IETF process does not have a notion of membership, and there are no corporations -- only individual contributors (who sometimes happen to have the institutional backing of their corporation, a nice coincidence). There is no voting, only rough consensus on the mailing list. The result of this is that individual contributors (with or without corporate affiliation) can and do make a big difference, and are one of the primary reasons why IETF standards typically are of high technical quality.
The Projects and Software page lists some commercial products that contain support for DAV.
Q. Are there any major open-source projects for DAV?
A: There are quite a few projects that are being developed. Here are four that are active:
- 1 mod_dav: a DAV module for Apache. 2 sitecopy: a tool for copying web sites from a local system up to a web server. 3 cadaver: similar to a command-line FTP tool, this tool provides for easy, direct interaction with a DAV server. 4 Goliath: a DAV client application and a DAV library for the MacOS operating system.
There are a few other projects in development, but source has not yet been released.