[Owncloud] ownCloud API

Fri Jun 29 13:58:36 UTC 2012

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.

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.

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.
-- 

 - Robin Appelman

On Fri, 29 Jun 2012, 13:45:00 CEST, Frank Karlitschek <frank at owncloud.org> wrote:

> 
> On 28.06.2012, at 03:43, Michael Gapczynski <mtgap at owncloud.com> wrote:
> 
> > On Tuesday, June 26, 2012 10:56:38 PM Frank Karlitschek wrote:
> > > On 26.06.2012, at 22:17, Tom Needham <tom at owncloud.com> 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
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/owncloud/attachments/20120629/b61110d2/attachment.html>