On Friday, 12 May 2017 00:05:59 CEST Albert Astals Cid wrote: > El dimarts, 2 de maig de 2017, a les 19:58:05 CEST, Volker Krause va escriure: > > On Tuesday, 2 May 2017 00:07:43 CEST Albert Astals Cid wrote: > > > El diumenge, 23 d’abril de 2017, a les 12:52:57 CEST, Volker Krause va > > > Should submissionInterval and encouragementInterval also be a property > > > in > > > Provider? > > > > I only added properties needed for a QML configuration user interface so > > far, but if someone wants to do the entire setup in QML it probably makes > > sense to expose the entire API indeed. > > +1 i think we should start thinking more in "which are the qproperties that > make sense to expose" instead of the "what are the ones that i actually > need". > > Though i guess adding new qproporties is abi and api compatible it's always > nice if someone that has other needs doesn't need to add the qproperty at a > later stage.
Done, and Aleix added properties for SurveyInfo, so we are getting closer to full QML usability, with Discover being the guinea pig for that. > > > I see you protected the data on the server with a user/password. > > > > It's protecting both read access on the data and write access on product > > configuration and survey campaigns, yes. It would probably make sense to > > separate those two interfaces, and thus also enabling different access > > control for data analysis and product/campaign management. > > +1, i'd like at least a "read" and an "admin" privilege separation, if i > understand we plan to run this as a "KDE-wide service". That's implemented now. > > > If the data is really anonymous do we really need user/password ? > > > > Good point, I would also argue that for building trust in such a system > > the > > data must be public. However, there are two reasons that still made me > > protect it: > > (1) if it's world-readable the fact that it is essentially world-writable > > (see above problem with submitting wrong data) makes this easily > > exploitable for spreading links to illegal content, same as e.g. our > > pastebin was abused. > > Apply the same solution we made for pastebin? i.e. i think you need an > identity account now? Right, which should now be doable with the option of having read-only access to the data. Regards, Volker
signature.asc
Description: This is a digitally signed message part.