incubator-wookie-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sharples <p.sharp...@bolton.ac.uk>
Subject Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Date Wed, 11 May 2011 11:02:00 GMT
On 11/05/2011 11:56, Scott Wilson wrote:
> 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)

Thats what i thought, but just checking this is how you intended to 
continue to do it.

+1

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


Mime
View raw message