[Owncloud] modularization
Klaas Freitag
freitag at owncloud.com
Tue Feb 14 15:09:56 UTC 2012
On 12.02.2012 20:56, Frank Karlitschek wrote:
> Hi everybody,
>
> it´s 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 extend ownCloud without the need to understand every part of ownCloud. My goal is that every ownCloud user can install, update and delete every app independently from the used ownCloud core. Every app developer should be able to release a new app at every point in time and also update it independently from the core. The apps should run on different core versions if possible.
>
> It´s 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 owncloud directly. This means that it´s difficult to develop an app that runs on different core versions and the code will get messy over time. I think we should define a "public api" that wraps all the internals, is perfectly documented and stable over different core versions. We can add new classes, functions and optional function parameters over time but we don´t want 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" where 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 external 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
More information about the Owncloud
mailing list