is a server side library for implementing WEBDAV servers. It can be used in transactional business applications with relational databases, or content management systems, etc.
Using Milton consists of implementing a few interfaces and configuring a servlet into your application. Then your users can browse your data using file browsers such as windows explorer, finder or nautilus and edit your data using regular desktop applications such as MS Office.
New features in 1.5.x include:
- better support for dependency injection
- digest authentication
- unified PROPFIND and PROPATCH,
- custom properties can be implemented as pojo properties with a single annotation
, just like property binding in web frameworks like struts!
- Quota support
- improved AJAX to WEBDAV gateway
, so you can perform web authoring on your WEBDAV data in a nice Web 2.0 UI! Includes support for http authentication from forms
- improved integration with Apache FTP.
Milton has example applications to help you get started
Message was edited by: staff
people still use WebDav?
Only because there's no better web-based filesystem. And no, that's not a compliment to WebDAV, more a sad indictment of the state of this particular corner of technology...
Well I use it everyday, but I suppose thats no surprise seeing as i'm milton's author :)
To put it simply: This is the age of the web, and the web is HTTP, and webdav is HTTP. Get it?
For one thing, there is just no better way to upload files to a website, and to manage a remote file system. There's nothing to download because every OS has a usable client built in which works (enough, anyway). Conventional FTP servers are only any good if your resources are in a physical file system (which rules out any CMS or businss app). And FTP precludes host based clustering, so you'll probably be stuck with a single point of failure.
And, of course, FTP gets shut down my most corporate firewalls. HTTP doesnt.
At a superficial level you're right, "WebDAV is HTTP", but when you start digging into it you realise just how many poor design decisions were made. To their credit, the WebDAV folks have done an amazing job of documenting the mistakes they made - for example in the "WebDAV Book of Why" . The world would be a better place if this level of reflection was conducted by all specification groups...
Hey, that makes for really interesting reading! I've often wondered how those working group meetings must have gone. Its hard enough getting an agreement from 3 devs sitting around a table, let alone a whole bunch of people from different organisations from all around the world!
But i think they're being overly critical. Issues about dereferencing properties really arent relevant to simple desktop integration, eg browsing files in windows explorer, which is at least 99% of what webdav gets used for.
Mind you, I'd like to see custom properties used a lot more for business apps, and a major focus of this release has been to make that easier - hence the pojo property binding thing, and the ajax/json bridge.
The worst thing to happen to webdav was Windows Vista. Its webdav support was horrible (useable, but only just). But i think the best to happen will be Windows 7. From the testing i've done so far i'd say its good, and might even be the best native os webdav client. And just in time too. Now everyone's got permanent internet access via their mobile devices the need for web-capable file management is rapidly increasing (G-Drive, anyone?)
So maybe, just maybe, we're about to enter webdav's golden age!
What you do think about CMIS as the WebDAV of 2010 ?
Wow, there's some support behind it. Alfresco and IBM, who would have thought it.
But given that its taken MS 15+ years to get a working webdav implementation, how long will it take for them to come up with a CMIS one?
Has it been tested with litmus (http://www.webdav.org/neon/litmus/
To answer my own question: yes it has been tested with litmus - http://milton.ettrema.com/compat/index.html
(scroll down to the bottom).
I'll get back in my box now...
To be honest, we havent re-run that test since the 1.5.x refactoring. I'd expect generally better compliance, but little things that can go unnoticed.
Will check it out again and republish the results.
Is there an adapter or something to expose a JSR 170 content repository using Milton?
Not yet. I think Jackrabbit and Alfresco are the leaders in JCR170, and they each have their own webdav implementation, so i guess there's not much call for it.
But i'd be happy to help anyone who wanted to knock one up, i'm sure it would be easy.
Interesting. I see it's been integrated with dotCMS but are there any adapters to integrate it with other content systems?
I dont know of any other content management adapters. but milton is routinely integrated into systems, usually in a matter of hours or days, so its really no big deal.
You basically just need to implement getChildren() for your folder resource. There's a few other methods like getName() and getContentType(), but its all pretty simple.
Most of the webapps are deployed in a cluster. Is it possible to edit files on one of the instance in the cluster and the result synchronized across cluster. The solution seems to be use NFS or some shared derive mechanism but have other folks done something similar.
You could use a shared drive and that should work fine. I believe that one of the milton contributors does this on a large scale. Or you could also use JDBC persistence. I've got a JDBC implmentation which i intend to release, and i think a few other guys have built them. Its pretty straight forward.
Note that there are 2 other cluster-specific concerns to consider:
- locking: if you use locking then lock data needs to be available across the cluster.
- digest authentication: if you use digest authentication, the server generated 'nonce' values must be available across the cluster
In both cases you've got a choice of
- storing that data in a db,
- or hold the data in memory and synchronise somehow (eg terracotta, jgroups etc)
Milton allow pluggable implementations of both.
CMIS and WebDAV have slightly different goals. WebDAV is a protocol that leaves much of the semantics of the underlying system alone, and just treats it as files and properties. CMIS is a full domain model about document management, document versioning, change logs, search, etc.
I'm not saying WebDAV cannot do what I just described about CMIS, but just that CMIS is much more focused on what it does. Note that CMIS also defines a SOAP binding for its operations, which is very useful for application writers.
Also in the OASIS CMIS Technical Committee some people have already voiced their interest having a WebDAV-based transport for CMIS... but we had to stop somewhere otherwise there will never be a CMIS 1.0. So 1.0 will have AtomPub and SOAP.
The Apache Chemistry project (http://incubator.apache.org/chemistry/
) contains a CMIS client and server implementation written in Java. In it we offer AtomPub and SOAP bindings, but it would be relatively simple to also provide WebDAV bindings — and such bindings could very well use Milton!
Actually, we're building a Milton-based WebDAV server using the Chemistry CMIS API:
Disclaimer: it's not finished yet, based on an old version of Chemistry (the 0.62 branch), I only ever tested it with our own repo (http://www.flexive.org
), and operations are limited to basic create/update/delete of binary contents.
Milton is pretty straightforward to work with, it's a great library to build WebDAV servers...
still looking for a ant/maven webdav replacement to the slide work from years ago — haven't seen one yet.
the reason is specifically thing's you've stated above. inconsistent support from OSes. mac, xp, vista, linux all have variations may or may not work with a given server. but i'd like to have a build script that can get/post files to a webdav server regardless of which OS it is running on. (well, "get" usually works fine as it is built in to ant - but not it is not a copy-like get with filesets, etc.)
everytime i run across this problem (ant webdav) it surprises me that there has been no improvement since slide.
milton uses maven build scripts and is deployed to a webdav repository (which, of course, is milton) by the maven script.
ant might be a different story, but at least from maven it works fine!