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.
The nasty surprise was doing the server-side (for a hobby-project), many layers. Luckily found out that something called DavTest exists (it's included with Debian) so testing most basic things wasn't too bad.
Then tried mounting from Windows and running into a bunch of small issues (iirc you need to support locking), got it to mount before noticing notes about a 50mb file-size limit by default (raisable.. but yeah).
It's a shame it's all such a fragmented hodge-podge because adding SMB (the only other "universal" protocol) to an application server is just way too much complexity.
> 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
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".
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.