On 28.06.2012, at 03:43, Michael Gapczynski <[email protected]> wrote:
> On Tuesday, June 26, 2012 10:56:38 PM Frank Karlitschek wrote: >> On 26.06.2012, at 22:17, Tom Needham <[email protected]> wrote: >>> On 26 Jun 2012, at 21:15, Bart Visscher wrote: >>>> On Tue, Jun 26, 2012 at 04:17:37PM +0100, Tom Needham wrote: >>>>> Yes I'd say api.php would be most logical and least confusing. >>>> >>>> What is confusing about remote.php/api >>> >>> What I meant to say is that a separate api would be most logical and least >>> confusing, instead of trying to extend the OCS api. Yes this could easily >>> be remote.php/api.> >>>> Bart >> >> I´m biased here of course. ;-) >> >> But I think we should create a new module for our API as part of the OCS >> standard. This has some benefits because OCS is already an accepted >> freedesktop.org standard and implemented by a lot of other software. It is >> designed in a modular way so that we can easily create a new "cloud" module >> for our stuff but we still benefit from the existing concepts like provider >> abstraction, authentication and others. >> >> ownCloud is already an OCS client and an OCS server so it would be a logical >> step to follow this concept. >> >> >> >> Frank > > 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
