Cool. Let me know if I can help.
On 29.06.2012, at 15:53, Michael Gapczynski <[email protected]> wrote: > Well I'm satisfied with that, I'll start writing up some stuff for a cloud > module. > > > 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
