[Owncloud] Missing methods in public namespace
thomas.mueller at tmit.eu
Mon Sep 16 07:35:13 UTC 2013
Thanks a lot for your comments - as usual very welcome!
as I need to focus on the API at the moment I'll comment only on that parts.
I added your requests to this issue where I want to track all missing API functions:
Please push any further requests there - THX
Am Montag, dem 16.09.2013 um 5:06 schrieb Christian Reiner:
> Hi Thomas,
> this is a good action you take, thanks!
> On Monday 16 September 2013 02:18:58 Thomas Tanghus wrote:
> > I'm trying to collect what we need to get in the public namespace, and the
> > ones listed below are what I've found so far, and my suggestion for
> > placement, or questions on the same:
> * Please add some version formats to be queried.
> This includes two aspects:
> 1.) I usually implement all my apps such that they can be installed in
> multiple OC versions. So unlike the apps written by the OC team itself my apps
> are backwards compatible. The main motivation for this is that the store at
> apps.owncloud.com still (after two years...) is not able to support multiple
> versions of an app, depending for example on the OC version a user has
> installed. However to do this my apps have to know the OC version. Currently I
> have to use string operations to handle this! So I suggest to publish
> OC::getVersionString() next to OCP\Util::getVersion().
> 2.) And another thing that absolutely would ease version comparisions would be
> if you could stop call pre versions of upcoming releases still by the major
> version of the current release. Example: pre releases of OC-5 were called
> verison 4.8.96 for example. This is pretty annoying if you try to implement
> backwards compatibility, since a) you cannot simply test for the major version
> (we are talking about runtime checks here!) and b) you have to *guess* what a
> version actually means.
> * Since there still is no dependency management (or at least dependency check)
> for apps implemented (why not?) all apps have to perform all checks by itself
> (or take the risk...). My Shorty-Tracking app for example only makes sense
> when the main Shorty app is installed. If not, what is to be done? Exactly:
> the app disables itself again leaving a log entry. This is obviously done
> using OC_App::disable(). So I suggest to publish this method, or, preferable,
> finally implement a requirements check for apps.
> * I miss basic things like OC_Appconfig::getValue() in the public interface...
> * the current paradigm that apps are only loaded for session based requests
> (so for authenticated users) is much to strict in my eyes.
> I have to use OC_App::loadApps() in one case to be able to track requests via
> the public service to the Shorty app. You mention this app, but perfect would
> be a variant to load specific apps, so something like OCP\loadApp(...).
> The same is true for other situations: I still think it would be a great thing
> to implement apps offered to users NOT logged in. So for guests, stuff like a
> homepage app inside owncloud. I mean if you offer a personal cloud and think
> of sharing stuff with people that way, then it is an absolute natural thing
> that I should also be able to use this cloud (whatever a cloud is in this, I
> still don't really know...) to present information about myself. I mean isn't
> that what a cloud is all about? Keeping and offering information? Currently
> this is not possible, since for non-authenticated requests no apps are loaded.
> Period. Why?
> Probably it does not make sense to load all apps. That is why I suggested an
> additional app category more than a year ago: "public"...
> * OC_Group::inGroup() is something I miss too...
> (this is just what comes to my mind without actually checking my code)
> Christian Reiner (arkascha)
> Owncloud mailing list
> Owncloud at kde.org
More information about the Owncloud