On 29.06.2012, at 15:58, Robin Appelman <[email protected]> wrote:
> I dont think extending ocs will be a good idea for the specific api's, ocs > made sense for the private data key value store because that is a very > generic api. using ocs for things like versioning or rss mostly adds > unnecesairy overhead imo. and while attica might bring an advantage for kde, > implementing the new modules into attica isn't significant less work as > writing a simple implementation for the api with a decent toolkit. Well you don´t have to use attica. The API is very simple to use without or with a different library. But it´s good to have the option IMHO. > > for non-kde attica only brings an aditional dependecy and is unlikely to be > addopted by i.e. gnome, while wide adaption should be one of the main > concerns with the api. it would be a real shame if akregator would be the > only rss reader to support oc syncing and we dont want to end up being only a > cloud sollution for the kde desktop. Well you can always access it without attica. It´s just REST. But if you want to convinience you can use attica. And there are already other implementations for glib or python http://opendesktop.org/content/show.php/PyContent?content=108958 http://opendesktop.org/content/show.php/libopengdesktop?content=107669 > > where no existing standards exists (rss, versiong) we should try to work > together with the developers of as many different potentials clients as > possible instead of trying to extend ocs. Sure. We can and should still do that :-) > -- > > - Robin Appelman > > On Fri, 29 Jun 2012, 13:45:00 CEST, Frank Karlitschek <[email protected]> > wrote: > > > > > 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 > > _______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
