Add extra layer in DAV to accomodate for other services like versions, trashbin, etc #12543
Comments
|
That's really cool, it means that tag management could simply be done by getting/posting/putting/deleting to: https://domain.tld/owncloud/remote.php/dav/tags/ |
which will then finally be our REST-API 🙊 |
I like that 👍 |
|
How would those api's map to webdav? (Also we can drop the |
|
how to bring in pure share information? |
but then you need to duplicte a hell of code to fure up the sabre server - furthermore the used objects have dependencies - e.g. the principal route I'm referring to - see #12504 (comment) furthermore - there is one webdav entrypoint then - this is desired |
|
We are talking about files only, right? Or could If we talk about files only I would remove |
Yes, I think it would make a lot of sense to use the same API for shares. |
I already updated the description above - everything should be under one url - refs #5939 |
|
I'm not sure if putting everything under the same dav root makes it easier than making things a seperate dav endpoint, things like card and caldav need to setup sabre/dav in a different way then regular webdav. Trying to move all the different backend logics in a single dav enpoint would only make things complicated imo |
|
This is something that we should probably experiment at some point (hence the "research" label). @icewind1991 if carddav/caldav wouldn't work well, would having tags/sharing and others still work ? Or did you mean none of them would work ? |
|
@evert pointed out here #12504 (comment) that we could also include the user name in the WebDAV URL. This also means that we could have truly unique resource URLs. |
|
Other might work and even card/caldav can probably be made to work with it, but I think that instead of trying to push separate backends in a single dav endpoint we should try and reduce the boiler place needed to setup new dav endpoints and make it as easy as possible for apps to do that. sabre/dav provides a great system for creating multiple dav endpoints with seperate logic behind it, implementing the same thing on another layer seems like a waste |
|
FWIW, I tend to agree with Robin. Having separate endpoints for separate backends makes it a lot easier to define a nice API which only contains stuff which is really needed for the given backend. For example calendar and contact doesn't have a trashbin or versions. If everything uses the same endpoint it would depend on the resource you access which service exists and which not. Or you will specify the backend indirectly with URLs like Maybe I'm influences by the share API, but I think it makes it much easier for both the developer who write the API and the developer who will use it later if you keep it separated and create the best possible experience for each endpoint. |
|
I'm curious what the perceived drawback is of splitting these up. There's definitely some overhead to combining all endpoints into a single sabredav You would still only have some functionality at segments of your API instead of everywhere, but you also get some benefits... both caldav and carddav need principals, and if one day you also want to support RFC3744 (ACL) on files, you're already prepared for it. You can totally just push down specific functionality (versions, trash) further down the tree. Is it possible that this issue exist because all functionality is provided by one or a few node-classes in owncloud? |
as of today we have three node implementation:
we will for sure add more implementations for all these various resources as described above - in case we walk this path - to-be-decided |
|
Things to think about:
|
|
regarding the discussion about using a single sabredav object to handle all resource - please have a look at this code piece from the group-office project. This is an implementation of the root collection: http://sourceforge.net/p/group-office/code/HEAD/tree/trunk/www/modules/dav/fs/RootDirectory.php with some dynamic function we can provide the same mechanism for us - I see no need to duplicate the work in multiple endpoints |
|
But they dont seem to use a custom tree implementation |
well - they do - but their object tree holds no special logic for files ... I see your point now ... let's see how this evolves 🙈 |
|
I think multiple DAV instances is the way to go, as each instance can have different plugins. I did an experiment here with a tags endpoint, for fun: #12867 |
maybe add a very simple instance to the root of the entrypoint which lists all available resources. regarding the routing of that new dav entrypoint we have multiple options:
|
|
I still find it a bit confusing that we have so much files related end points on the same level, wouldn't it make sense to group them all below So that we would have
|
this will not work because under files the files will be listed and this will conflict with files/versions |
|
I think we also need to give a good though about how to represent relations / how to link entities of different type. For example file <-> tags, file <-> versions. One of the trickiest parts could be the sharing API. Also:
|
|
@PVince81 see #12884 for a research PR that implements SEARCH. DAV:basicsearch has several components: o DAV:select provides the result record definition. |
|
Does it mean "SEARCH" needs to be used in all cases, as replacement for PROPFIND ? (some kind of paginated PROPFIND ?) |
|
Some thoughts regardfing the versions endpoint: #10571 |
|
@icewind1991 I see your point about CalDAV/CardDAV needing to setup Sabre differently. If you go the single endpoint route proposed by @DeepDiver1975, it would mean that every plugin needs to be able to filter itself out by checking if the path is actually for them. For example a CardDAV plugin would need to check whether the requested route is indeed under "dav/carddav". If yes, then go on, else return. I don't think plugins should be aware of that, so for now I'd rather go with @icewind1991's suggestion and a utility method. |
|
Note that all sabre/dav plugins are already built to only add their own behavior for relevant paths. Generally they don't really do that based on the path though, but usually:
To a certain extent the system is designed to do this, but I do agree that there's a bit of overhead. There's also great advantages though. If you follow both the 'single root' and the 'embed the user id in the url' rules, it means that you can actually use the 'path' of any resource as a primary key for many things, which is really the correct way to do a lot of this stuff. |
|
In the case of a mixed tree, I guess it might work as we'd have an implementation of ObjectTree that sits at the base and delivers different node implementations for different paths. So if the plugins are all working with specific node types (ex: trash plugin working with TrashedFile nodes), then it could work. Note that in the case of trashed files or versions, we wouldn't invent a new content-type but reuse the original file's content-type, so content-type based detection would not work here. |
|
Hm.. can you get rid of the custom objecttree implementation? I think your implementation might be a lot simpler if you do. All you need is a root node that correctly instantiates these sub-nodes, instead of doing it on the objecttree-level. |
|
Right, the root node. I think I need to do more exercises with Sabre 😉 |
|
@DeepDiver1975 you forgot to advertise your POC here 😉 |
|
So, will part of this be in 8.2? I will be able to get the list of files contained in a folder from my mobile app, posting the path to Will uploading be supported? If the endpoint is going to change, thumbnails should be replaced by preview |
|
Unlikely. The linked repo is just a proof of concept and more design/research work needs to be done to decide what the best approach is for the endpoints. |
|
@DeepDiver1975 the new layer has been added in 9.0. The other services/endpoints can be added as part of their respective apps/features. |
|
Well, unless we want to keep this ticket to discuss possible extensions like search and returning JSON objects ? I'll reopen 😄 |
|
Is there any documentation - or code which could serve as such - on how to add a new endpoint from within an application? |
|
There is currently no public API for external apps to add their own endpoints in "remote.php/dav". @DeepDiver1975 we need to discuss this. For now, apps should still register endpoints like they did before under "remote.php/myappendpoint" pre 9.0. |
|
I think it's a good thing because if an app starts registering |
|
We already have the layer, closing in favor of #20047 |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
See #12504 (comment)
The idea is to add an extra subdir in the WebDAV URL.
Since there is a risk of breakage if we do it in the existing
https://domain.tld/owncloud/remote.php/webdavthen I suggest to add another entry point called "dav":https://domain.tld/owncloud/remote.php/dav/fileshttps://domain.tld/owncloud/remote.php/dav/files_versionshttps://domain.tld/owncloud/remote.php/dav/files_trashbinhttps://domain.tld/owncloud/remote.php/dav/files_favoriteshttps://domain.tld/owncloud/remote.php/dav/tags/tagname/https://domain.tld/owncloud/remote.php/dav/thumbnailshttps://domain.tld/owncloud/remote.php/dav/calendarshttps://domain.tld/owncloud/remote.php/dav/addressbookshttps://domain.tld/owncloud/remote.php/dav/files_chunks/folder/file.txt/{transferid}/{chunkIndex}https://domain.tld/owncloud/remote.php/dav/usershttps://domain.tld/owncloud/remote.php/dav/groupsand we keep the old WebDAV one
https://domain.tld/owncloud/remote.php/webdavfor backwards compatibility.Note: I guess some of the "tags/favorites" can probably be achieved using a "SEARCH" method instead.
The text was updated successfully, but these errors were encountered: