[Owncloud] modularization

[Bartek Przybylski]

2012/2/12 Frank Karlitschek <frank at owncloud.org>

>
> On 12.02.2012, at 21:44, Bartek Przybylski wrote:
>
> > 2012/2/12 Frank Karlitschek <frank at owncloud.org>:
> >> 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.
> >
> > I put this topic in the picture multiple times on irc, unfortunately
> > no one never took care about it, lets hope that after project founder
> > says something it will be noted.
>
> Hehe. I suggest to discuss important stuff like this on the mailinglist.
> Not everybody reads IRC all the time.
>
> >
> > Are you also thinking about providing REST api for external apps so OC
> > might be embeeded to users websites ? (like public "trash can")
>
> Thats a very interesting idea. I haven´t thought about that but that an
> interesting direction.
> That exactly would be the usecase for the end user?
>
> I´m interested in your ideas :-)
>
>
My idea of public API is to provide single entry point to OC instance ie in
JSON format. OC will be able to handle such request iff some app will
register for such rqeuest and provide handling mechanism.
Profits for developers:
* no need to worry for providing easy and secure entry to its apps
* ease of developing 3rd party tools (ie browsers extensions, jquery
plugins for WP etc)
Profits for end users:
* more tools which will allow them to interact with their OC instance
* no need to remember very long path to some app (ie
OC/apps/NAME/ajax/some_script_name.php?ARG1=VAR1&... should be shorten to
ie OC/access <- arguments passed by POST/GET)
Profils for OC devs: fame and glory ;)

if i can i would like to take deep cooperation in designing and
implementing public API ;)


>
> >>
> >>
> >> - 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.
> >> 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?
> >>
> >>
> >> Cheers
> >> Frank
> >> _______________________________________________
> >> Owncloud mailing list
> >> Owncloud at kde.org
> >> https://mail.kde.org/mailman/listinfo/owncloud
> > _______________________________________________
> > 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/20120214/e6a18f95/attachment.html>