I previously succeeded to mount the files from a gin repo with WebDAV. However, just now I have been trying this again from the same machine and client (the macOS Finder) and failing. In the meantime, however, I have updated macOS to Catalina. To help me debug the problem further, can you please suggest a WebDAV client which is known to work? I have also just tried cyberduck and davix-git.
Also, for publicly available repositories, do I need to login with WebDAV, or can I do anonymous login?
I [previously succeeded](https://gin.g-node.org/G-Node/Info/issues/27#issuecomment-244) to mount the files from a gin repo with WebDAV. However, just now I have been trying this again from the same machine and client (the macOS Finder) and failing. In the meantime, however, I have updated macOS to Catalina. To help me debug the problem further, can you please suggest a WebDAV client which is known to work? I have also just tried cyberduck and davix-git.
Also, for publicly available repositories, do I need to login with WebDAV, or can I do anonymous login?
Hi again Andrew. I have some updates on the status of WebDAV support.
Due to some internal changes, we've decided to keep WebDAV support disabled for now. However, we will be bringing API access to GIN file contents, which was part of the original issue you opened a few months ago (#27).
I hope this isn't too disruptive to your workflow. Please let me know if you have any further questions or concerns.
Hi again Andrew. I have some updates on the status of WebDAV support.
Due to some internal changes, we've decided to keep WebDAV support disabled for now. However, we will be bringing API access to GIN file contents, which was part of the original issue you opened a few months ago (#27).
I hope this isn't too disruptive to your workflow. Please let me know if you have any further questions or concerns.
WebDAV is pretty convenient in that it allows use of the files without copying to the local computer. For built-in OS clients, it means that programs without specific support can use remote data with no intermediate copies. So, this might be worth keeping in mind as something for the future.
The HTTP API certainly is appealing as well! Perhaps this belongs on #27: are you implementing the S3 API? I think this would make sense as a lot of storage backends support that and thus potential users could more easily switch to gin as a storage backend if they see specific advantages to it. At the same time, this would minimize the risk associated with investing in gin, because the same code could be used to directly use a more generic backend. Of course, I do not know your design goals and constraints, so maybe an S3 API is not well suited.
WebDAV is pretty convenient in that it allows use of the files without copying to the local computer. For built-in OS clients, it means that programs without specific support can use remote data with no intermediate copies. So, this might be worth keeping in mind as something for the future.
The HTTP API certainly is appealing as well! Perhaps this belongs on #27: are you implementing the S3 API? I think this would make sense as a lot of storage backends support that and thus potential users could more easily switch to gin as a storage backend if they see specific advantages to it. At the same time, this would minimize the risk associated with investing in gin, because the same code could be used to directly use a more generic backend. Of course, I do not know your design goals and constraints, so maybe an S3 API is not well suited.
I realise there are many storage services that implement S3 and making GIN compatible would be good for compatibility with existing tools, but since GIN is git based, a big part of the S3 API wouldn't make sense. We might consider adding a subset of it in the future as a convenient alternative, but I would prioritise WebDAV over this since clients for it are even more widely available (a lot of OS file browsers implement it, as you mentioned).
The [GOGS project](https://github.com/gogs/gogs) which GIN is based on implements a [GitHub compatible API](https://docs.github.com/en/rest/reference/repos#contents), so we'll soon have the [content access parts of that API](https://github.com/gogs/docs-api/blob/master/Repositories/Contents.md).
I realise there are many storage services that implement S3 and making GIN compatible would be good for compatibility with existing tools, but since GIN is git based, a big part of the S3 API wouldn't make sense. We might consider adding a subset of it in the future as a convenient alternative, but I would prioritise WebDAV over this since clients for it are even more widely available (a lot of OS file browsers implement it, as you mentioned).
I previously succeeded to mount the files from a gin repo with WebDAV. However, just now I have been trying this again from the same machine and client (the macOS Finder) and failing. In the meantime, however, I have updated macOS to Catalina. To help me debug the problem further, can you please suggest a WebDAV client which is known to work? I have also just tried cyberduck and davix-git.
Also, for publicly available repositories, do I need to login with WebDAV, or can I do anonymous login?
Hi Andrew, thanks for bringing this to our attention. This seems to be a serverside issue so your client(s) should be fine.
I'm looking into it now.
Hi again Andrew. I have some updates on the status of WebDAV support.
Due to some internal changes, we've decided to keep WebDAV support disabled for now. However, we will be bringing API access to GIN file contents, which was part of the original issue you opened a few months ago (#27).
I hope this isn't too disruptive to your workflow. Please let me know if you have any further questions or concerns.
WebDAV is pretty convenient in that it allows use of the files without copying to the local computer. For built-in OS clients, it means that programs without specific support can use remote data with no intermediate copies. So, this might be worth keeping in mind as something for the future.
The HTTP API certainly is appealing as well! Perhaps this belongs on #27: are you implementing the S3 API? I think this would make sense as a lot of storage backends support that and thus potential users could more easily switch to gin as a storage backend if they see specific advantages to it. At the same time, this would minimize the risk associated with investing in gin, because the same code could be used to directly use a more generic backend. Of course, I do not know your design goals and constraints, so maybe an S3 API is not well suited.
The GOGS project which GIN is based on implements a GitHub compatible API, so we'll soon have the content access parts of that API.
I realise there are many storage services that implement S3 and making GIN compatible would be good for compatibility with existing tools, but since GIN is git based, a big part of the S3 API wouldn't make sense. We might consider adding a subset of it in the future as a convenient alternative, but I would prioritise WebDAV over this since clients for it are even more widely available (a lot of OS file browsers implement it, as you mentioned).
That indeed all makes sense. I'll close this issue for now.