incubator-wookie-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Wilson <scott.bradley.wil...@gmail.com>
Subject Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Date Wed, 11 May 2011 10:56:02 GMT

On 11 May 2011, at 11:47, Ross Gardler wrote:

> 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?

Yes, the REST API for admin features uses HTTP Basic Auth by default (but can be configured
for whatever sort of authentication the servlet container can offer)

> 
>> I'm just wondering if there are any other "gotchas" we'll only find later.
> 
> Bound to be ;-)
> 
> Ross


Mime
View raw message