On 26 February 2013 11:52, Paul Sokolovsky <[email protected]> wrote: > Hello, > > On Fri, 22 Feb 2013 17:08:43 +0000 > James Tunnicliffe <[email protected]> wrote: > >> Hi Paul, >> >> Thanks for looking at this. The problem with this approach is changes >> to the web interface will break the tool. > > Yes, but *one* tool. Previously, we had (well, still have) bunch of tool > breaking in random placed and times. So, having single tool to fix is > already big improvement over what we had and exactly the requirement > put into implementing that.
The reason why we have so many tools is because we didn't officially support one. I seem to recall that this was because we didn't have a clear answer about how such a tool should work in terms of presenting licenses and caching acceptances. I did write a tool/library that was pretty close to allowing licenses to be displayed and permanently accepted, but there wasn't any enthusiasm for getting those extra features finished so it remained yet another download bypassing the license protection tool. I don't think writing yet another tool is better than fixing an existing one and supporting it. >> We should put the complexity >> in the server code and make clients trivial. > > Well, most of our clients for that are shell-based, so we need > shell-based "API layer" anyway. That is why I suggested an API that could easily be interacted with using pretty much anything. >> Adding an API to >> linaro-license-protection that is independent of page rendering >> wouldn't be difficult (1 day of work - it is mostly copy/paste from > > Famous last words ;-). We definitely need general publishing/access API > for our file storage infrastructure which would cover all usecases > we've been hitting for a long time. Designing, passing thru review, > implementing such API is not a 1 day task though... I agree that review is always an unpredictable delay, but I really don't think writing it to what Antonio and I have discussed would take longer than a day since it is just adding a couple of URLs to the existing web interface. We are talking about adding a couple of JSON listings and a new GET method that looks for the license hash in a custom header instead of reading it from a cookie. You could probably modify the existing code to make it look for the license hash in the header first and if that failed look for a cookie in a few lines. It is such a small change that adding it as an experimental interface is the easiest way to see if it works for everyone! > So, the ideas are good and I appreciate them (having similar feeling for > the need of it), but let's first get everyone on the same line regarding > using one supported tool, and perfectalize its implementation later. > > In that regard, I'd really like to get feedback on licensing handling > (UI interaction wise) - unless you're lawyer, you can never be sure it's > done right, and I'd hate something obvious to be missed and pop up > later. Which is why I stuck to an API that required the client to interact with the license in the same way that the web interface works (which uses a hash of a license stored in a cookie to accept the license). We already can't enforce that the user sees the license and the scripts that avoid it completely aren't helping. -- James Tunnicliffe _______________________________________________ linaro-validation mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-validation
