2 ms·

I have a fun experiment for OP, since you already walked the reverse engineering route. Why not download the most popular DAV libraries from various languages,

by didip 9mo ago

I have a fun experiment for OP, since you already walked the reverse engineering route. 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.

candiddevmike 9mo ago
Author here, we don't use generative AI for software development. We've been building since 2018, and our number one goal has always been ensuring our software remains maintainable.
- mbreese 9mo ago
  Those two things aren’t mutually exclusive. It may be worthwhile to at least have Claude (or whatever LLM you favor) to look at the other libraries and compare it to yours. It doesn’t have to write the code, but it could point out areas/features you’re missing.
  - deleted 9mo ago
    [deleted]
  - candiddevmike 9mo ago
    We know what we're missing (a lot, we didn't implement the full spec). We don't know what weird edge cases the clients/servers will have, and I would bet you decent money a LLM won't either. That's why manual testing and validation is so important to us.
    - mbreese 9mo ago
      I wouldn’t be so sure about the LLM not helping. The LLM doesn’t need to know about the edge cases itself. Instead, you’d be relying on other client implementations knowing about the edge cases and the LLM finding the info in those code bases. Those other implementations have probably been through similar test cycles, so using an LLM to compare those implementations to yours isn’t a bad option.
- mystifyingpoi 9mo ago
  > Author here, we don't use generative AI for software development. You don't have to use it to directly write code. You can use it just for the analysis phase, not making any changes.
  - astrange 9mo ago
    I've tried that (with Sonnet 4.5 at least, not Opus) and Claude isn't good at code analysis because it's too lazy. It just grepped for a few things and then made the rest of it up. 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.
- BeetleB 9mo ago
  > Author here, we don't use generative AI for software development. How close to retirement are you?
- brongondwana 9mo ago
  Did you use the 'litmus' test suite? I found it very useful when building Fastmail's (perl) WebDAV file server implementation. 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).

by didip 9mo ago

candiddevmike 9mo ago

Author here, we don't use generative AI for software development. We've been building since 2018, and our number one goal has always been ensuring our software remains maintainable.

mbreese 9mo ago
Those two things aren’t mutually exclusive. It may be worthwhile to at least have Claude (or whatever LLM you favor) to look at the other libraries and compare it to yours. It doesn’t have to write the code, but it could point out areas/features you’re missing.
- deleted 9mo ago
  [deleted]
- candiddevmike 9mo ago
  We know what we're missing (a lot, we didn't implement the full spec). We don't know what weird edge cases the clients/servers will have, and I would bet you decent money a LLM won't either. That's why manual testing and validation is so important to us.
  - mbreese 9mo ago
    I wouldn’t be so sure about the LLM not helping. The LLM doesn’t need to know about the edge cases itself. Instead, you’d be relying on other client implementations knowing about the edge cases and the LLM finding the info in those code bases. Those other implementations have probably been through similar test cycles, so using an LLM to compare those implementations to yours isn’t a bad option.
mystifyingpoi 9mo ago
> Author here, we don't use generative AI for software development. You don't have to use it to directly write code. You can use it just for the analysis phase, not making any changes.
- astrange 9mo ago
  I've tried that (with Sonnet 4.5 at least, not Opus) and Claude isn't good at code analysis because it's too lazy. It just grepped for a few things and then made the rest of it up. 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.
BeetleB 9mo ago
> Author here, we don't use generative AI for software development. How close to retirement are you?
brongondwana 9mo ago
Did you use the 'litmus' test suite? I found it very useful when building Fastmail's (perl) WebDAV file server implementation. 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).