> Now before you mention NIH syndrome, yes, we looked at the existing Go implementation, go-webdav. This library was lacking some key features we needed, like server-side collection synchronization, and the interfaces didn’t really align with our data model. This is also going to be a key feature of our product, so we should have some level of ownership for what gets implemented.
This is a different, non x/net library.
> You just need to wrap it in a main.go and boom, webdav server.
Lol
I created a test LMS in 2003 based on SCORM, at the time there really wasn't a good server for the standard... The main point was to be able to test the content which the company was hired to generate. I didn't implement several points of functionality that I just didn't need, didn't care about, and would have been difficult to implement.
That testing LMS turned into an actual product used by several aerospace companies (a few F100's, etc) and was in production for over 15 years. I remain friends with the company owner... It was about 12 years later than someone had an actual course that used one of the features that wasn't implemented... and even then, they only implemented it the half way needed, because it would have been difficult to do the rest.
What a strange process... why not read the source code of an open source working library (easy to test, run a client made by someone else on its server, and vice versa) in a language close to the target?
Why not use then those tests as a way to verify your own work after?
FWIW I'm using WebDAV, both with clients and with my own self hosted servers, on a daily basis and... it works.
One niceish thing about WebDAV/CalDAV is it's pretty set in stone for now.
I don't know if you've ever heard "Latin is a dead language"; many people think that statement is a somewhat negative-sentiment one, amounting to something along the lines of "there's no good reason to learn Latin, it's dead", but I've heard that it's actually supposed to be a positive-sentiment statement, something like "we can have confidence that contemporary interpretations of this text haven't changed in the last ~1800 years because the language itself stopped changing around then".
Why not download the most popular DAV libraries from various languages, Java, C++, PHP, etc. Regardless how ancient they are.
And then have AI like Claude to analyze and bring in the improvements to your own Go library?
I was doing something like that for Kerberos and Iceberg Rest Catalog API, until I got distracted and moved on to other things.
There were also a bunch of fun things with quirks around unicode filename handling which made me sad (that was just a matter of testing against a ton of clients).
As for CalDAV and CardDAV - as others have said, JMAP Calendars/Contacts will make building clients a lot easier eventually... but yeah. My implementation of syncing as a client now is to look for sync-collection and fall back to collecting etags to know which URLs to fetch. Either way, sync-collection ALSO gives a set of URLs and then I multi-get those in batches; meaning both the primary and fallback codepath revert to the multi-get (or even individual GETs).
You don't have to use it to directly write code. You can use it just for the analysis phase, not making any changes.
I think the issue is mostly that it desperately tries to avoid filling its context window, and Anthropic writes system prompts that are so long it's practically already full from the start.
A good harness to read code for you and write a report on it would certainly be interesting.
How close to retirement are you?
I picked it because it's in a language I know (Python) and free and copyleft. These days I don't contribute to anything unless it's copyleft.
No idea if it supports family calendar, I need to look into that as well at some point.
EDIT Just checked and supports auth, yes.
It used to be a constant headache to keep running, but ever since I switched to the TrueNAS/Docker plugin it has worked smoothly. I know a lot of other people also have had good luck with the much lighter Radicale if CalDAV is your primary concern.
It’s been very easy to run for me since version 15 or something. Basically i just use the stock docker image and mount a few files over there. The data folders are bind-mounded directories.
As usual with anything php, it’s only a mess if you start managing php files and folders yourself. Php has a special capability of making these kind of things messy, i don’t know why.
Yes! This is my #1 issue with the library as well.
Love the libraries BTW. Thank you for all of your hard work.
If there's actual employer IP in there then just leaving said employer wouldn't magically clear it.
If there isn't and you're just trying to avoid red tape, then publishing it anonymously would work around the issue.
If there is an actual IP issue then even waiting after you’re out of the company will not resolve said IP issue. If you’re using your employer’s IP then waiting is unlikely (both legally and especially morally) to magically resolve it - it’s still your employer’s IP.
If it’s just to avoid red tape but otherwise the IP is yours and has nothing to do with your employer (aka you could’ve done it just as well even if you weren’t at your current employer, and your employer’s competitive advantage is not based on having a good WebDAV implementation) then it should be fine and you’re just taking a shortcut to save time on both sides.
Basically, if your employer is a vendor of WebDAV libraries, yeah of course there’s a (legal, or a least moral) issue. If not, then all fine.
(Obviously this is just opinion and not legal advice - but legality only matters if they can figure out who did it ;)
Some employers have an unbelievably unreasonable interpretation of non-compete and IP. They think they own everything their employees do, and even though they're wrong. That doesn't stop them from ruining you and whatever unfortunate open source project they set their sights on with vexatious litigation.
Thus the suggestion to publish anonymously.