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