-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 W dniu 14.10.2010 04:19, Michael Hudson pisze: > It has to be said, I'm not sure the aesthetic appeal of oauth outweigh > these costs. It smells a bit overengineered.
Alternatives? >> 1) We need to allow users to authenticate before we allow them to upload >> test results (bundles) to certain directories (bundle streams) in a >> simple and efficient manner (client side code matters) > > Is this all we want? As salgado asked in another mail, where is this > API going? Currently that's the only thing we _require_. We will want more things but I'd like to solve one problem at a time. >> 2) Currently our only client is abrek > > Is this going to change? Most likely it's going to grow to more programs. I'd like to ship an official client-side library that programs like abrek can use to be isolated from how we do stuff internally. >> 3) We'd like to offer this very quickly, definitely before the UDS > > I don't think we should allow time pressures to force us into a bad > decision. That said, I'm not sure the decision being made here is > necessarily that bad to get "wrong" at this stage. While I agree I also value the act of shipping useful stuff even if we need to clean some bits up later on. Having said that, I don't think the "bad" scenario is that wrong either. >> Having said that let's look at the options we have: >> >> A) Continue hacking oauth in good faith that it'll work as intended >> without falling apart/being insecure/being hard to deploy/missing deadlines. > > I think the tone of your voice suggests you don't like this plan :-) If I used oauth before and knew if like the back of my hand I'd be more optimistic here. My primary concern is that 1) we'll miss deadline 2) it's not going to be pretty on the client side 3) we'll get it wrong somewhere. >> Some other points to consider: >> 1) Offspring nee lexbuilder also has an XML-RPC interface (cody, please >> correct me if I'm wrong) and we should align the technology if >> possible > > I don't really see the value in this, tbh. If cody has to solve the same problem then we could at least share the solution later on. > Given that UDS is so soon, is there much value on working on it > furiously before UDS, where the real requirements might become clear? > Having authentication doesn't seem a requirement for doing demos at the > summit to me. I think it solves an important aspect of having some sensibility to how we push our data. Currently anyone can push anything anywhere. That's just bad IMHO. It's not devastating but not something I'd like to give. Regards ZK -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMtrX3AAoJEKkR4hQBRI+lS1IIAKih0+coeq+UsFzSVl5aHbe0 kryGTi8VLbUZz6MYhgS0hu3kHqTOEHpZButZU0IwFs0GF15/Zvwgcmc77EhivjLe NA1ItPFR4KvvDc1HK2tYnCQkLL/yRsHn5rH671RfLy2hiP6nVz4kiICiexD+n7nd rD/uUfx9XFmUcRG5REsbSLw5Y0FZCfC51kncKtMi5Y8818zQz3DoFxn33Gn8HWyj t2ZY9dfp7IPJ9V/LlhSLsTV1to50NRghQaASI30MTwBjrj3+Ue8j+XnWXoSuVzmh GkT2NDU8Er2bfdDwcUWNkX7QH+hpOhnTMhwv36Y1fBZtyrpw84p9o3W4YLpiMn0= =AsxF -----END PGP SIGNATURE----- _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
