Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Share API 2.0 #13014

Closed
6 tasks
schiessle opened this issue Dec 23, 2014 · 6 comments
Closed
6 tasks

Share API 2.0 #13014

schiessle opened this issue Dec 23, 2014 · 6 comments

Comments

@schiessle
Copy link
Contributor

I think it become more and more clear that we need to improve the share API in a way that makes it no longer possible to keep the API stable. There is just to many old, broken and confusing stuff. Just one extremely confusing example: the "shareWith" parameter in shareItem() is used for the password for public link shares. Also other stuff we want to change anyway will result in large changes, e.g. reorganizing the re-share behaviour (#9058). So we should take the chance and do it right.

Possible target release: 8.2

Suggested way forward:

We implement a share API 2.0 and make sure to migrate all apps in time (files, calendar and contacts). Depending on the changes to the database structure we can deprecate the old API and keep it around for 1-2 releases. But I think if we manage to upgrade all the apps in parallel this wouldn't be necessarily needed and would make changes to the DB probably a lot easier.

What should change:

  • move away from the static classes
  • share API should not care about share type (at the moment there are a lot of "if shareType ==foo then ... else ..." this shouldn't be there)
  • share table shouldn't distinguish between "item_source" and "file_source" and stuff like that, for the share api/table exerything should be a item, period.
  • the API should become a lot easier, the API should mainly read/write the shares to the table everything else should be handled by the back-ends because only the back-ends know the best way to handle their share types.
  • ideally the API will come with a OCS/REST/WebDAV API, needs to be decided and can also be added later
  • ...

I think this way we will reduce a lot of complexity, improve performance and make the code maintainable again. Also the new API should be more fun to use than the current one.

@schiessle
Copy link
Contributor Author

Let's discuss the way forward @DeepDiver1975 @karlitschek @icewind1991 @PVince81 @nickvergessen @butonic

@karlitschek
Copy link
Contributor

sounds reasonable

@DeepDiver1975 DeepDiver1975 added this to the 8.1-next milestone Jan 17, 2015
@PVince81
Copy link
Contributor

PVince81 commented Feb 4, 2015

A suggestion has been made here to use entity mappers to make it easier to use the share API on PHP level: #13424

@DeepDiver1975 DeepDiver1975 modified the milestones: 8.2-next, 8.1-current Mar 2, 2015
@MorrisJobke
Copy link
Contributor

Cc @rullzer

@MorrisJobke
Copy link
Contributor

Closing inf favor of #19331

@lock
Copy link

lock bot commented Aug 6, 2019

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.

@lock lock bot locked as resolved and limited conversation to collaborators Aug 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants