About WebDAV: using Independentsoft client ..

Facing an integration task using WebDAV brought me to take a look closer at WebDAV and corresponding tools for .Net platform. This is part of a short series:

• About WebDAV: using IT Hit client
• About WebDAV: using Independentsoft client
• About WebDAV: do it yourself

-----

Another commercial client - WebDAV .NET from Independentsoft, priced 299 EUR and up.

What do I need ?

The simplest scenario you can get from WebDAV:

• List folder contents, get name/urls, size, differentiate files & subfolders
• upload a file from memory
• download a file to memory

For testing purposes I use IIS 7.5 as my WebDAV server.

What Does it do?

Homepage promises compatibility to WebDAV RFC 2518.

Only interesting fact from homepage is support for ANY .Net Framework, including Compact Framework and Mono.

What did I get ? / How did I do it ?

Once again, I achieved my supersimple goals.

Initializing the client:

var session = new WebdavSession();
session.Credentials = CredentialCache.DefaultNetworkCredentials;
var resource = new Resource(session);

This Resource thingy is weird, but I hope it makes sense to somebody. Now, fetching contents and showing only files ..

var selectProperties = new PropertyName[] { DavProperty.DisplayName, DavProperty.IsCollection, DavProperty.GetContentLength };
foreach (var item in resource.List(folderUri.ToString(), selectProperties))
{
   if (item.Properties[DavProperty.IsCollection].Value == "1") { continue; }
   Console.WriteLine("{0} ({1} bytes)",
      item.Properties[DavProperty.DisplayName].Value,
      item.Properties[DavProperty.GetContentLength].Value
   );
}

I really like that I can enumerate the properties I’m interested in and the choice of valid names are accessible using DavProperty container. Downside is that the seemingly simple and universal API requires me to check for the existance of given properties in output (not done in sample) and parse-interpret the values. It is straightforward considering the protocol, but the resulting code is not the cleanest. Now, to downloading..

using (var stream = new MemoryStream())
{
   resource.Download(folderUri.ToString() + "/bb.txt", stream);
   var contents = Encoding.Default.GetString(stream.ToArray());
}

Almost as simple as it gets – download that URI into that stream. How about upload?

var newFileName = "NewFile_" + DateTime.Now.ToString("dd-HHmmss") + ".txt";
var content = "Whatever content";

using (var stream = new MemoryStream(Encoding.Default.GetBytes(content)))
{
   resource.Upload(folderUri.ToString() + "/" + newFileName, stream);
}

Once again elegant -  data from this stream to this url.

What do I think ?

Simple, straightforward, efficient – exactly the way you want your libraries to be. On the downside for trickier parts you better (get to) know what happens in the protocol level. Using the default configuration it provided seemingly optimal traffic. If I had the licence, I would use it for my WebDAV needs.

The good:

• decent API
  • default scenarios are made quite simple.
  • with xmldoc.
• Commercial product but
  • Has evaluation option (30 days)
  • even entry level licence has royalty-free redistribution with your software.
  • source code option is available (for extra fee)
• Seems fast
  • For example: list properties you are interested.
  • with default settings: 3 tasks = auth challenge + 3 request-response pairs in HTTP track
  • approx 42 ms

• Supports Compact Framework & Mono
  • official Mono support is no common. A good cause!
• Nice attitude from support
  • On evaluation request I got a mail from a specific developer in Independentsoft stating that if I have problems or need examples then he’ll try to help (“usually in few minutes”). It was an automated message, but still – encouraging!

The bad:

• Commercial product
  • 300 EURs for starter is a bit heavy for simple needs in a single project
  • They do want your email for evaluation version.
• Homepage says it is based on RFC 2518 which is an obsolete specification and is marked to be superseded by RFC 4918.
  • Not sure what’s the difference in real world but it is a sign of worry, because RFC 4918 seems to be from June 2007.
• Code may be straightforward but not always as clean as it could be.
  • for example : reading property values after PROPFIND