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