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 09:49:58 GMT
On 11/05/2011 10:27, Ross Gardler wrote:
> On 11/05/2011 09:25, Steve Lee wrote:
>
>> One thought is that in order to ease evaluation by new users/devs a
>> global installer would be be useful, or at least clear signposting
>> between the projects.
>
> Naturally. I'm proposing that Rave become the official reference 
> implementation of a UI for Wookie. Our site would reflect this 
> accordingly.
>
>>> Wookie is focussed on providing a server based environment for the 
>>> hosting
>>> of Widgets and Gadgets. It provides the necessary infrastructure for 
>>> clients
>>> to request a widget/gadget instance (or a wgt package if 
>>> appropriate). It
>>> also provides a persistence layer so that widgets/gadgets can store
>>> preference values. Wookie does not concern itself with the rendering of
>>> those widgets/gadgets.
>>
>> I may be getting confused but doesn't Wookie also implement Wave APIs
>> - do these really belong there as well? But that's another
>> discussion....
>
> I'm not sure where "there" is. I don't think it is important for this 
> proposal which is only concerned with UI. However, for completeness, I 
> believe the Wave integration we currently have belongs here. In the 
> long term we should consider adopting Apache Wave for this rather than 
> the partial local implementation we currently have. However, there is 
> currently no use case so lets stay focussed (for reference Rave has 
> Wave features on its long term objectives list so a relationship with 
> the Rave community now would be a good thing in the future too).
>
>>> 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?

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

>
>>> We may choose to provide text based output from this API, although
>>> I would suggest an XSL transformation of the XML responses from the API
>>> would be most appropriate as this will allow data to be retrieved in
>>> multiple formats (CSV, text, HTML etc.)
>>
>> That sounds good. However without getting too sidetracked JSON does
>> provide easy consumption in many cases (but might not be appropriate
>> here). For the straight-street.com API [1] I ended up serving JSON
>> mime type with minimal formating to ease reading. using the Firefox
>> JSONView plug makes it pretty and then interacting and exploring is
>> really easy through the hyperlinks
>
> Sure we can provide JSON too - we look forward to your patch or and 
> XSLT to convert XML to JSON, e.g.
>
> wookie listWidgets [PROPERTIES] --transform=toJSON.xslt
>
> or
>
> wookie listWidgets [PROPERTIES] --output=JSON
>
>>> We should offer all UI code in Wookie to Rave as a starting point 
>>> for their
>>> "Gadget Store". I imagine that the majority of this code will be 
>>> re-written
>>> by the Rave team to suit their local needs. However, I also imagine 
>>> that the
>>> work they do will greatly enhance the work we have done here and, 
>>> for those
>>> people who need a stand alone administration UI for Wookie we can 
>>> point them
>>> towards Rave.
>>
>> +1
>
> Thanks for your comments.
>
> Ross
>
>>
>> 1: http://straight-street.com/api/
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1209 / Virus Database: 1500/3618 - Release Date: 05/05/11
>


Mime
View raw message