[prev in list] [next in list] [prev in thread] [next in thread] 

List:       owncloud
Subject:    Re: [Owncloud] modularization
From:       Klaas Freitag <freitag () owncloud ! com>
Date:       2012-02-14 15:09:56
Message-ID: 4F3A7944.20507 () owncloud ! com
[Download RAW message or body]

On 12.02.2012 20:56, Frank Karlitschek wrote:
> Hi everybody,
>
> it=B4s importants that we structure ownCloud properly so that the code is=
 still maintainable in a few years and that new developers understand what =
we do and can contribute.
>
> The app concept is very important to make it easy for developers to exten=
d ownCloud without the need to understand every part of ownCloud. My goal i=
s that every ownCloud user can install, update and delete every app indepen=
dently from the used ownCloud core. Every app developer should be able to r=
elease a new app at every point in time and also update it independently fr=
om the core. The apps should run on different core versions if possible.
>
> It=B4s of course still a long way till we reach that goal but I think we =
should start now.
>
>
> I propose to do two things now.
>
> - public api
> Currently all the apps access all the internal classes and variables of o=
wncloud directly. This means that it=B4s difficult to develop an app that r=
uns on different core versions and the code will get messy over time. I thi=
nk we should define a "public api" that wraps all the internals, is perfect=
ly documented and stable over different core versions. We can add new class=
es, functions and optional function parameters over time but we don=B4t wan=
t to break existing apps. This public api is the only allowed way to access=
 core features.
Maybe we should split up to a couple of APIs, such as a
- Filesystem/Storage API
- Contacts API
- Calendar API
- ...

This way, apps could also provide APIs for other apps - or do I get =

something wrong?

Each of this API could maintain a version. Maybe we even should adopt =

the/one common scheme of major/minor versions in terms of backward =

compatibility.
I doubt we can live without any kind of versioning as ownCloud evolves.

If an app is installed or started, it should somehow register at the =

core with its required versions of the APIs. It is checkable than if the =

app can run at all by checking the required against the provided =

versions. Moreover, the user or admin could get warnings like on Android =

(and others?): "The app wants to use the XY-API. It requires Version 3, =

Version 5 is installed. Do you want to allow that?" That might =

especially be useful if apps can be installed online.

> - git modularization
> I suggest to split up ownCloud into a "third party" repository where all =
the external libraries are,  "owcloud" where the core lives and "apps" wher=
e all the apps are. The =

apps should be as isolated from the core as possible so that we can =

release them independently in the future. We discussed this already last =

year.
But it will be possible to host apps somewhere else and deploy just be =

submitting a tarball or so?

> An independent "third party" repo is also important if we want to use ext=
ernal third party libraries with incompatible licenses like currently PEAR.
>
> I will restructure the repos and start to work on the public api wrapper =
on wednesday if no one objects. :-)
>
> So what do you think?
Cool...

Thanks,

Klaas
_______________________________________________
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud
[prev in list] [next in list] [prev in thread] [next in thread]