On 11/05/2011 10:49, Paul Sharples wrote:
On 11/05/2011 10:27, Ross Gardler wrote:
On 11/05/2011 09:25, Steve Lee wrote:

...

Proposal
========

Wookie should deprecate all UI code and provide integration with Rave,
thereby allowing Rave to host W3C Widgets as well as OpenSocial
gadgets. Our
UI will no longer be interactive. All administration activities will be
carried out via a command line application, interfacing with Wookie
via the
REST API.

Util now Wookie has required simple UI to allow basic evaluation
testing and developing. If these functions move to another project, I
would suggest that stand-alone unit tests would still be required at a
minimum, and perhaps a simple demo. It seems much of this could be
done with some mock widgets and the command line / REST access.

I'm saying *no* UI code. Wookie becomes a library. The moment we start
bringing UI code back in for any reason we start to blur the lines.

Testing is not a problem (in fact it is simplified) and instructions
for instantiating a widget and viewing it in browser would be just a
few lines long. In fact there is no reason why the CLI couldn't
optionally fire up a browser when a widget is instantiated.

e.g. wookie instantiate [WIDGET_ID] [PROPERTIES] --view

ok, I can see the logic in doing this now, but my only other question is
how we handle authentication to the admin facilities. (i.e at the moment
you have to "login" to the admin section to do certain things using the
web UI). Do we still keep the existing wookie authentication for this?

The REST API needs to handle authentication. The CLI should communicate via the REST API. I don't see that this is any different than accessing remotely.

I'm not familiar with the current authentication process. Is this possible?

I'm just wondering if there are any other "gotchas" we'll only find later.

Bound to be ;-)

Ross

Reply via email to