[Owncloud] Missing methods in public namespace

[Thomas Müller]

Hi Christian,

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:
https://github.com/owncloud/core/issues/4863

Please push any further requests there - THX

Tom

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
> https://mail.kde.org/mailman/listinfo/owncloud