[Owncloud] modularization

[Melvin Carvalho]

On 20 February 2012 21:05, Frank Karlitschek <karlitschek at kde.org> wrote:

>
> On 20.02.2012, at 20:14, Thomas Wanderer <newsabos at nurfuerspam.de> wrote:
>
> > Am 12.02.2012 20:56, schrieb Frank Karlitschek:
> >> 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.
> >>
> >>
> >
> > Hello everyone! This is my first post here after following this project
> for a while and having (had) similar plans for a web-based central sync
> service for personal use.
> >
> > @modularization: I find this quite important! Being a Synology Disk
> Station user for some time I noticed that they want to break their
> web-frontenddown into a core and modular applications too...wow...of course
> this are not the big news but I thought it might be helpful as another
> source of input to see what other (commercial) projects plan. If OC makes
> this step I think it's quite important to define what is in core and what
> is an "app".
> >
> > Thomas
>
>
> Hi Thomas,
>
> thanks for your input. Apps are the way we structure ownCloud. If a
> project is growing it´s important to divide a software in sub modules,
> otherwise it will get messy over time, especially with PHP ;-) Our modules
> are called apps. If you look at the sourcecode you see that basically
> everything in ownCloud is an app which is good because it means that we
> have a structure. ;-)
>
> Please note that the modularization has nothing to do with what we
> actually ship. Of course we will ship several apps as default because
> otherwise ownCloud wouldn´t be that useful. ;-)
>
> This is an interesting point. Before the next release we need to decide
> which app is ready for inclusion in the release and what app need some more
> polishing. This is something we have to discuss here on the list a few
> weeks before the next release.
>

Hi Frank

My first post here.

Modularization of apps is definitely a good thing.  I'm helping out on the
unhosted project where we are trying to build a modular infrastructure for
separating apps and data.  Also I'm doing some work with the distributed
information group at MIT to achieve the same ends.  The broad goal is
ambition and that is to decouple apps and data at web scale.  So an
owncloud app can work with unhosted and vice versa, but also imagine
extending this to all web scale apps and data stores.  Quite exciting stuff.

As the title implies modularity is the key.  I'm sure you probably know
from your KDE work that is goes one level deeper.  The real key is to give
resources a URI.  This makes them universal, or, first-class objects of the
web.  The fundamental principle of the web was (and still is) predicated on
this axiom.  It's probably the most overlooked architectural point in any
system, but also the opportunity to make your system both modular and
powerful.

As much or our work reaches a level of maturity I think the really fun
stuff is going to see how it all interops in new and exciting way.

Looking forward to getting to know owncloud better!


>
>
>
> Cheers
> Frank
>
>
> Frank Karlitschek
> karlitschek at kde.org
>
>
> _______________________________________________
> 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/20120220/3f71625e/attachment.html>