On 29.06.2012 15:53, Michael Gapczynski wrote:
Well I'm satisfied with that, I'll start writing up some stuff for a cloud
module.
Can we summarize concrete usecases for the API, what we want to provide
through it and to whom for example. I am kind of lost in the general API
discussion, but lost the view on what the API very specifically is for.
From the clients POV I could make use of API to:
- get information about the users quota
- get information about the serverside file list with metadata (all files)
- Shares info (not sure yet how that works)
- File revisions
what else?
A clear picture on what we want to achieve might help us to find the
best way to build the API.
regards,
Klaas
Michael
On Friday, June 29, 2012 01:45:00 PM Frank Karlitschek wrote:
On 28.06.2012, at 03:43, Michael Gapczynski<[email protected]> wrote:
I'm just worried that in this case someone will see the API is part of OCS
and then get confused when they start looking through the OCS spec
instead. It is designed for social networks correct?
Well, it can provide lot´s of different things. ownCloud is using it for
accessing and downloading of Apps and Knowledge Base entries for example.
ownCloud is also an OCS server for the key value storage and implements the
activities module to push events to the clients.
OCS is build in a modular way. Not everybody has to provide every module. We
would skip the social networking part obviously but implement a "cloud"
module and the other things we want to do.
I'm also a little confused about what a
provider is and why you have multiple providers on one server.
The idea is that a client can tak to several servers at the same time. So if
your syncing client has several ownCloud configured for example.
What can the software that already implements OCS do if ownCloud extends
OCS. Can we tie into the Social Desktop to find other ownCloud users
(inter ownCloud sharing) or display news (the sync client performed a
sync, a shared file was updated)? I might be wrong, but I believe that
Social Desktop does stuff with People and Activity. If we can do this
without changes to the existing software that implements OCS, then it
sounds like it might be worth it.
It can and should be completely independent. That´s where the modules
concept in OCS comes in. Every OCS provider only implements the modules
that make sense.
Another benefit is with using OCS is that we already have a full working ocs
REST interface in ocs.php We only have to add the mdule and the new calls
that we want to support. All the rest including authentification is already
done. So this should be very easy.
Another benefit is that OCS is already a freedesktop.org standard so it
would be more professional for us to just use and extend it instead of
inventing something completely new.
And one more benefit is that there is already a Qt implementation of the API
called attica. We only have to add our new call and the integration into
our sync client and KDE will be very easy.
If we go with extending OCS, I still believe that there should be an entry
point outside of ocs/v1/ just to make developers aware that this isn't the
full implementation of OCS.
This is also handled by the the providers concept. In providers.php is
defined which modules/servies are implemented on this server. Currently
only "activities". In the future we can extend this with our new "cloud"
module.
Frank
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
