You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Ross Gardler <rg...@apache.org> on 2011/05/10 17:17:49 UTC
[PROPOSAL] Wookie gadget "store" moved to Rave?
I'd like to propose that some of the code here in Wookie be moved over
to Apache Rave (Incubating). I feel that it is more likely to be
maintained and enhanced there. The code in question is present in Wookie
in order to make Wookie usable, but it is not (IMHO) part of the core
objective of Wookie.
If my proposal is accepted it will mean that Wookie would not carry any
UI code. Instead it would focus on providing a server for the management
of widget instances. This would not change the headline goal of Wookie
("Apache Wookie is a Java server application that allows you to upload
and deploy widgets for your applications").
The issue I'd like to discuss in this thread is just where the split
between Rave and Wookie lies. Since Rave is starting from a blank slate
it makes sense to do this here and then discuss our conclusions with the
Rave project.
Rationale
=========
Apache Rave (Incubating) [1] is developing an OpenSocial Gadget
potrtal-like framework. It is stated that it is intended to also support
W3C Widgets. Scott and myself are involved with both the Wookie and Rave
projects.
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.
Rave is a server that focusses on the provision of user interfaces built
from widgets/gadgets. It provides UI features for end users to configure
their portal pages. It does not concern itself with how a widget/gadget
is hosted, instead it seeks to leverage OpenSocial for gadgets and,
potentially, Wookie for Widgets.
These two applications overlap at the point of the "widget/gadget
store". Wookie provides a basic UI for the administration of a store,
but also exposes an API to manage this store. Wookie also provides a
very basic interface (and functional API) for the creation of
widget/gadget instances.
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. 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.)
We should also focus on development of appropriate connectors so that
Wookie widgets/gadgets are presented as part of multiple hosting
environments. Our primary focus will be the Java connector which will be
used to provide full integration with Rave.
If the Rave team so desire they can adopt the API defined by our Java
Connector to allow swappable replacement of widget servers (OpenSocial
and Wookie being the obvious choices at this point).
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.
Thoughts?
Ross
[1] http://incubator.apache.org/rave
Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Posted by Ross Gardler <rg...@apache.org>.
On 10/05/2011 19:44, Scott Wilson wrote:
> On 10 May 2011, at 16:17, Ross Gardler wrote:
...
> Making sure all Wookie's functionality is exposed by REST API should
> be a priority - some things (API key management, registering
> OpenSocial gadgets) currently aren't and we should fix that.
>
> Second, providing XSLT to make the results of REST API calls more
> useful is a good idea.
>
> So, irrespective of the view of the proposal as a whole, I think the
> above should be added to Jira anyway (I'll do that soon...)
+1
>> Thoughts?
>
> I like the idea of making Wookie more lightweight and modular;
> delegating the whole concept of an admin client to Rave is an
> attractive thought from that perspective. I already largely manage
> Wookie from the command line anyway - e.g. dragging and dropping in
> Widgets to /deploy rather than going through the web interface. I
> mostly use the web interface for some interactive debugging these
> days.
>
> I'd previously looked into providing Wookie admin functions as
> widgets (this is in the scratchapad area). These too could be
> submitted to Rave.
+1
Implementing the admin UI as widgets in Rave means that other platforms
(with suitable connectors) can then become the admin UI.
> (Note also I've worked on a prototype using an Apache Solr repository
> implementation to support searching and browsing across multiple
> widget/gadget providers - this might also be of interest to Rave:
> http://iecbolton.jira.com/svn/ITEC/widget_discovery_service/trunk/)
I'll let you bring that idea to Rave in your own time. It sounds great.
Ross
>
>>
>> Ross [1] http://incubator.apache.org/rave
>
Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Posted by Ross Gardler <rg...@apache.org>.
On 11/05/2011 09:28, Paul Sharples wrote:
> On 10/05/2011 19:44, Scott Wilson wrote:
...
>>> 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.
>>>
>>>
>>> Thoughts?
>> I like the idea of making Wookie more lightweight and modular;
>> delegating the whole concept of an admin client to Rave is an
>> attractive thought from that perspective. I already largely manage
>> Wookie from the command line anyway - e.g. dragging and dropping in
>> Widgets to /deploy rather than going through the web interface. I
>> mostly use the web interface for some interactive debugging these days.
>>
>> I'd previously looked into providing Wookie admin functions as widgets
>> (this is in the scratchapad area). These too could be submitted to Rave.
>>
>> (Note also I've worked on a prototype using an Apache Solr repository
>> implementation to support searching and browsing across multiple
>> widget/gadget providers - this might also be of interest to Rave:
>> http://iecbolton.jira.com/svn/ITEC/widget_discovery_service/trunk/)
>>
>
> Are you saying that we should remove the UI type files from
> "webcontent/*" and move them to rave? (i.e the admin, webmenu folders of
> jsps etc).
I'm saying we should offer the code. Whether they want it is a different
issue.
The important point is...
> Wookie would then have no front end. Subsequently, things
> like settting a context for a widget (i.e. widget type equals "chat") or
> setting a white list entry, would then be done from the command line or
> through a connector from within wookie? (obviously the connectors need
> some more work to do this)
No, I'm not saying Wookie would have no front end. I'm saying the
reference front end would be Rave.
I'm suggesting we maintain a CLI, so that changes *can* be made through
the command line. However, I'm also saying that we should ensure the
REST API and our connectors are sufficiently functional to allow other
systems to become a front end for Wookie.
Scott has also suggested that we should explore the idea of providing
admin widgets. I think this is a great idea. This would allow, for
example, Moodle to become the admin UI. However, I don't think these
widgets should be here in Wookie, they should be in Rave (I've not
discussed this with the Rave community, I'm starting here).
Ross
>
> Just so I understand you correctly.
>
>>> Ross
>>> [1] http://incubator.apache.org/rave
>>
>
Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 10/05/2011 19:44, Scott Wilson wrote:
> On 10 May 2011, at 16:17, Ross Gardler wrote:
>
>> I'd like to propose that some of the code here in Wookie be moved over to Apache Rave (Incubating). I feel that it is more likely to be maintained and enhanced there. The code in question is present in Wookie in order to make Wookie usable, but it is not (IMHO) part of the core objective of Wookie.
>>
>> If my proposal is accepted it will mean that Wookie would not carry any UI code. Instead it would focus on providing a server for the management of widget instances. This would not change the headline goal of Wookie ("Apache Wookie is a Java server application that allows you to upload and deploy widgets for your applications").
>>
>> The issue I'd like to discuss in this thread is just where the split between Rave and Wookie lies. Since Rave is starting from a blank slate it makes sense to do this here and then discuss our conclusions with the Rave project.
>>
>> Rationale
>> =========
>>
>> Apache Rave (Incubating) [1] is developing an OpenSocial Gadget potrtal-like framework. It is stated that it is intended to also support W3C Widgets. Scott and myself are involved with both the Wookie and Rave projects.
>>
>> 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.
>>
>> Rave is a server that focusses on the provision of user interfaces built from widgets/gadgets. It provides UI features for end users to configure their portal pages. It does not concern itself with how a widget/gadget is hosted, instead it seeks to leverage OpenSocial for gadgets and, potentially, Wookie for Widgets.
>>
>> These two applications overlap at the point of the "widget/gadget store". Wookie provides a basic UI for the administration of a store, but also exposes an API to manage this store. Wookie also provides a very basic interface (and functional API) for the creation of widget/gadget instances.
>>
>> 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. 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.)
>>
> Making sure all Wookie's functionality is exposed by REST API should be a priority - some things (API key management, registering OpenSocial gadgets) currently aren't and we should fix that.
>
> Second, providing XSLT to make the results of REST API calls more useful is a good idea.
>
> So, irrespective of the view of the proposal as a whole, I think the above should be added to Jira anyway (I'll do that soon...)
>
>> We should also focus on development of appropriate connectors so that Wookie widgets/gadgets are presented as part of multiple hosting environments. Our primary focus will be the Java connector which will be used to provide full integration with Rave.
>>
>> If the Rave team so desire they can adopt the API defined by our Java Connector to allow swappable replacement of widget servers (OpenSocial and Wookie being the obvious choices at this point).
>>
>> 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.
>>
>>
>> Thoughts?
> I like the idea of making Wookie more lightweight and modular; delegating the whole concept of an admin client to Rave is an attractive thought from that perspective. I already largely manage Wookie from the command line anyway - e.g. dragging and dropping in Widgets to /deploy rather than going through the web interface. I mostly use the web interface for some interactive debugging these days.
>
> I'd previously looked into providing Wookie admin functions as widgets (this is in the scratchapad area). These too could be submitted to Rave.
>
> (Note also I've worked on a prototype using an Apache Solr repository implementation to support searching and browsing across multiple widget/gadget providers - this might also be of interest to Rave: http://iecbolton.jira.com/svn/ITEC/widget_discovery_service/trunk/)
>
Are you saying that we should remove the UI type files from
"webcontent/*" and move them to rave? (i.e the admin, webmenu folders of
jsps etc). Wookie would then have no front end. Subsequently, things
like settting a context for a widget (i.e. widget type equals "chat") or
setting a white list entry, would then be done from the command line or
through a connector from within wookie? (obviously the connectors need
some more work to do this)
Just so I understand you correctly.
>> Ross
>> [1] http://incubator.apache.org/rave
>
Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Posted by Steve Lee <st...@fullmeasure.co.uk>.
On 10 May 2011 19:44, Scott Wilson <sc...@gmail.com> wrote:
> On 10 May 2011, at 16:17, Ross Gardler wrote:
>
>> I'd like to propose that some of the code here in Wookie be moved over to Apache Rave (Incubating). I feel that it is more likely to be maintained and enhanced there. The code in question is present in Wookie in order to make Wookie usable, but it is not (IMHO) part of the core objective of Wookie.
> Making sure all Wookie's functionality is exposed by REST API should be a priority - some things (API key management, registering OpenSocial gadgets) currently aren't and we should fix that.
+1
Full admin without need to RSH would be a powerful maotivator for adoption.
--
Steve Lee
Full Measure - open source accessibility - http://fullmeasure.co.uk
Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Posted by Scott Wilson <sc...@gmail.com>.
On 10 May 2011, at 16:17, Ross Gardler wrote:
> I'd like to propose that some of the code here in Wookie be moved over to Apache Rave (Incubating). I feel that it is more likely to be maintained and enhanced there. The code in question is present in Wookie in order to make Wookie usable, but it is not (IMHO) part of the core objective of Wookie.
>
> If my proposal is accepted it will mean that Wookie would not carry any UI code. Instead it would focus on providing a server for the management of widget instances. This would not change the headline goal of Wookie ("Apache Wookie is a Java server application that allows you to upload and deploy widgets for your applications").
>
> The issue I'd like to discuss in this thread is just where the split between Rave and Wookie lies. Since Rave is starting from a blank slate it makes sense to do this here and then discuss our conclusions with the Rave project.
>
> Rationale
> =========
>
> Apache Rave (Incubating) [1] is developing an OpenSocial Gadget potrtal-like framework. It is stated that it is intended to also support W3C Widgets. Scott and myself are involved with both the Wookie and Rave projects.
>
> 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.
>
> Rave is a server that focusses on the provision of user interfaces built from widgets/gadgets. It provides UI features for end users to configure their portal pages. It does not concern itself with how a widget/gadget is hosted, instead it seeks to leverage OpenSocial for gadgets and, potentially, Wookie for Widgets.
>
> These two applications overlap at the point of the "widget/gadget store". Wookie provides a basic UI for the administration of a store, but also exposes an API to manage this store. Wookie also provides a very basic interface (and functional API) for the creation of widget/gadget instances.
>
> 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. 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.)
>
Making sure all Wookie's functionality is exposed by REST API should be a priority - some things (API key management, registering OpenSocial gadgets) currently aren't and we should fix that.
Second, providing XSLT to make the results of REST API calls more useful is a good idea.
So, irrespective of the view of the proposal as a whole, I think the above should be added to Jira anyway (I'll do that soon...)
> We should also focus on development of appropriate connectors so that Wookie widgets/gadgets are presented as part of multiple hosting environments. Our primary focus will be the Java connector which will be used to provide full integration with Rave.
>
> If the Rave team so desire they can adopt the API defined by our Java Connector to allow swappable replacement of widget servers (OpenSocial and Wookie being the obvious choices at this point).
>
> 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.
>
>
> Thoughts?
I like the idea of making Wookie more lightweight and modular; delegating the whole concept of an admin client to Rave is an attractive thought from that perspective. I already largely manage Wookie from the command line anyway - e.g. dragging and dropping in Widgets to /deploy rather than going through the web interface. I mostly use the web interface for some interactive debugging these days.
I'd previously looked into providing Wookie admin functions as widgets (this is in the scratchapad area). These too could be submitted to Rave.
(Note also I've worked on a prototype using an Apache Solr repository implementation to support searching and browsing across multiple widget/gadget providers - this might also be of interest to Rave: http://iecbolton.jira.com/svn/ITEC/widget_discovery_service/trunk/)
>
> Ross
> [1] http://incubator.apache.org/rave
Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Posted by Ross Gardler <rg...@apache.org>.
My initial proposal (below) has been well received and has prompted some
very encouraging discussion about a potential widgetstore sub-project.
I have modified the proposal to include the clarifications and
discussion in this thread and elsewhere and posted it to the Rave
project [1] for discussion.
Assuming it is well received over there too I'll bring it to a vote here
since it is a pretty major change for Wookie.
Ross
[1] http://markmail.org/message/avvgt2gyaq5kpxq2
On 10/05/2011 16:17, Ross Gardler wrote:
> I'd like to propose that some of the code here in Wookie be moved over
> to Apache Rave (Incubating). I feel that it is more likely to be
> maintained and enhanced there. The code in question is present in Wookie
> in order to make Wookie usable, but it is not (IMHO) part of the core
> objective of Wookie.
>
> If my proposal is accepted it will mean that Wookie would not carry any
> UI code. Instead it would focus on providing a server for the management
> of widget instances. This would not change the headline goal of Wookie
> ("Apache Wookie is a Java server application that allows you to upload
> and deploy widgets for your applications").
>
> The issue I'd like to discuss in this thread is just where the split
> between Rave and Wookie lies. Since Rave is starting from a blank slate
> it makes sense to do this here and then discuss our conclusions with the
> Rave project.
>
> Rationale
> =========
>
> Apache Rave (Incubating) [1] is developing an OpenSocial Gadget
> potrtal-like framework. It is stated that it is intended to also support
> W3C Widgets. Scott and myself are involved with both the Wookie and Rave
> projects.
>
> 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.
>
> Rave is a server that focusses on the provision of user interfaces built
> from widgets/gadgets. It provides UI features for end users to configure
> their portal pages. It does not concern itself with how a widget/gadget
> is hosted, instead it seeks to leverage OpenSocial for gadgets and,
> potentially, Wookie for Widgets.
>
> These two applications overlap at the point of the "widget/gadget
> store". Wookie provides a basic UI for the administration of a store,
> but also exposes an API to manage this store. Wookie also provides a
> very basic interface (and functional API) for the creation of
> widget/gadget instances.
>
> 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. 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.)
>
> We should also focus on development of appropriate connectors so that
> Wookie widgets/gadgets are presented as part of multiple hosting
> environments. Our primary focus will be the Java connector which will be
> used to provide full integration with Rave.
>
> If the Rave team so desire they can adopt the API defined by our Java
> Connector to allow swappable replacement of widget servers (OpenSocial
> and Wookie being the obvious choices at this point).
>
> 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.
>
>
> Thoughts?
>
> Ross
> [1] http://incubator.apache.org/rave
Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Posted by Steve Lee <st...@fullmeasure.co.uk>.
On 11 May 2011 10:50, Scott Wilson <sc...@gmail.com> wrote:
> Currently In the Controller class there is content-type support, it just requires for each Controller method that returns a representation that you implement a serializer in its respective Helper class. To get the different views you either send a content-type header in the request, or if you can't for some reason you can also add "?format=json" or whatever.
>
> e.g. in the WARP controller:
>
> switch (format(request)) {
> case XML: returnXml(AccessRequestHelper.createXMLAccessRequestDocument(accessRequests),response);break;
> case HTML: returnHtml(AccessRequestHelper.createAccessRequestHTMLTable(accessRequests),response);break;
> case JSON: returnJson(AccessRequestHelper.createJSON(accessRequests),response);break;
> }
>
>
> And in the whitelist controller:
>
> switch (format(request)) {
> case XML: returnXml(WhitelistHelper.createXMLDocument(entries),response);break;
> case JSON: returnHtml(WhitelistHelper.createJSON(entries),response);break;
> case HTML: returnHtml(WhitelistHelper.createHTML(entries),response);break;
> }
>
> (Going with Ross's proposal we'd remove the HTML option, or wire it to return XML with an XSLT)
That clarifies that question if XLST processing will be internal
Steve
Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Posted by Scott Wilson <sc...@gmail.com>.
On 11 May 2011, at 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
>
>>> 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
Currently In the Controller class there is content-type support, it just requires for each Controller method that returns a representation that you implement a serializer in its respective Helper class. To get the different views you either send a content-type header in the request, or if you can't for some reason you can also add "?format=json" or whatever.
e.g. in the WARP controller:
switch (format(request)) {
case XML: returnXml(AccessRequestHelper.createXMLAccessRequestDocument(accessRequests),response);break;
case HTML: returnHtml(AccessRequestHelper.createAccessRequestHTMLTable(accessRequests),response);break;
case JSON: returnJson(AccessRequestHelper.createJSON(accessRequests),response);break;
}
And in the whitelist controller:
switch (format(request)) {
case XML: returnXml(WhitelistHelper.createXMLDocument(entries),response);break;
case JSON: returnHtml(WhitelistHelper.createJSON(entries),response);break;
case HTML: returnHtml(WhitelistHelper.createHTML(entries),response);break;
}
(Going with Ross's proposal we'd remove the HTML option, or wire it to return XML with an XSLT)
>
>>> 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/
>
Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Posted by Steve Lee <st...@fullmeasure.co.uk>.
On 11 May 2011 10:27, Ross Gardler <rg...@apache.org> wrote:
> 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.
I thought you were saying no GUI, but still CLI or web API
That is then not a library but a process with a UI (thoug webAPI could
be a library/module).
> 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.
Nice idea, and use selenium to test.
However I was thinking of minimising dependencies for test purposes
(eg rely on a widget in another project).
--
Steve Lee
Full Measure - open source accessibility - http://fullmeasure.co.uk
Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Posted by Paul Sharples <p....@bolton.ac.uk>.
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
>
Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Posted by Scott Wilson <sc...@gmail.com>.
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
Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Posted by Ross Gardler <rg...@apache.org>.
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
Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Posted by Paul Sharples <p....@bolton.ac.uk>.
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
>
Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Posted by Ross Gardler <rg...@apache.org>.
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
>> 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/
Re: Core vs Non-Core
Posted by Ross Gardler <rg...@apache.org>.
+1 for commit - please ensure your docs below also go into the CMS
Sent from my mobile device (so please excuse typos)
On 11 May 2011, at 15:37, Scott Wilson <sc...@gmail.com> wrote:
>
> On 11 May 2011, at 12:29, Scott Wilson wrote:
>> On 11 May 2011, at 12:08, Ross Gardler wrote:
>>
>>> On 11/05/2011 10:21, Scott Wilson wrote:
>>>> Just kicking off a new thread here, as its something we need to think
>>>> about for future direction.
>>>>
>>>> The core purpose of Wookie is to be a W3C Widget server, however it
>>>> also does some "other stuff". At the moment, we build the whole
>>>> project in one go. However, it may be useful to have non-core modules
>>>> as optional builds rather than core functionality.
>>>>
>>>> Steve mentions Wave as one example. The Wave feature is a very nice
>>>> one, but isn't a core W3C Widget feature. So this might be factored
>>>> out into an optional module (you could use either the Java/DWR or
>>>> NodeJS implementations)
>>>>
>>>> Another one is JCR support. Currently Wookie is built with both JPA
>>>> and JCR persistence - should JCR be an optional, pluggable module
>>>> rather than built-in?
>>>
>>> How do you imagine these optional components being managed? At build time? At runtime?
>>>
>>> The holy grail would be auto-configuration at runtime. That is, if a widget indicates it requires a non-core feature Wookie tries to find an implementation, downloads it and installs it (obviously with tight admin controls).
>>>
>>> Currently we require features to be added at compile time. This is not very satisfactory. Whilst considering what is/is not core we perhaps ought to think about an extension mechanism too. I'm not suggesting holding up progress on this proposal until we have an extension mechanism ready. Buildtime configuration is fine as a starting point, but having a vision of where we think we are going would be a good idea.
>>
>> Yes, for feature installs I'd really like to do something better than what we have now. There really is no reason these have to be Java classes, they could just as easily be XML config files loaded at runtime; they were patterned after the Wave feature extension which had a lot more server-side custom code, but that may be better treated as the exception rather than the template.
>>
>> So a future model could be feature packages with:
>>
>> /myfeature
>> feature.xml
>> (various js and css files)
>>
>> ... where "feature.xml" is something like:
>>
>> <feature>
>> <name>http://jquerymobile.com</name>
>> <script src="jquery-1.5.min.js"/>
>> <script src="jquery.mobile-1.0a4-patched.min.js"/>
>> <stylesheet src="jquery.mobile-1.0a4.min.css"/>
>> </feature>
>>
>> (which is quite similar to how Shindig manages features)
>
>
> As this is something I've been meaning to do for ages, I added a ticket for it and went ahead and implemented this. Its quite a bit of refactoring (mostly deletions) but it doesn't look like it breaks any tests.
>
> The new approach loads Features on start by inspecting the /features folder of the local installation and then creating Feature objects for each valid feature.xml file. It holds these in a static List rather than saving them in the database (its only ever going to be a few small objects and doesn't need any query support).
>
> This could be extended relatively easily to include a folder watcher to dynamically install features (similar to widgets) or to dynamically discover and install features if they're needed for a widget (the UC Ross mentioned above) as Feature no longer require any compilation steps.
>
> I'm ready to commit this - I just wanted to give everyone a chance to comment/object before I went ahead.
>
>
>>
>>>
>>>> Here's my strawman:
>>>
>>> JQuery Mobile is one of many possible frameworks so I'd make this non-core.
>>>
>>> As a general guide I would say anything added as a <feature...> in config.xml should be non-core.
>>>
>>> I'd also make the widget examples non-core as they will clutter up a live install. It's easy enough to add something to the CLI along the lines of:
>>>
>>> wookie installPack widgetSamples
>>>
>>> This would get a list of widgets in the "widgetSamples" pack and deploy them to a running instance.
>>>
>>> I have an idea for how this "pack" thing could work. It's just a convenience for managing groups of widgets from the command line. If we manage to get runtime deployment of features then these packs could include appropriate features. I'll implement this in the CLI if we head in this direction.
>>>
>>>> (NB this is just the server, not the connectors sub-project)
>>>
>>> +1 I don't think any of the connectors should be part of core. They are for deployment on other platforms.
>>>
>>>> I'm not sure about "services" (effectively, tags) as to whether this
>>>> really is Wookie core functionality or something a "widget store"
>>>> like Rave's would add on top, e.g. user-generated tagging.
>>>
>>> I have no idea what they are for, so I guess they are not core for me ;-)
>>>
>>> Ross
>>
>
Re: Core vs Non-Core
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 11/05/2011 16:02, Scott Wilson wrote:
> On 11 May 2011, at 15:37, Scott Wilson wrote:
>
>> On 11 May 2011, at 12:29, Scott Wilson wrote:
>>> On 11 May 2011, at 12:08, Ross Gardler wrote:
>>>
>>>> On 11/05/2011 10:21, Scott Wilson wrote:
>>>>> Just kicking off a new thread here, as its something we need to think
>>>>> about for future direction.
>>>>>
>>>>> The core purpose of Wookie is to be a W3C Widget server, however it
>>>>> also does some "other stuff". At the moment, we build the whole
>>>>> project in one go. However, it may be useful to have non-core modules
>>>>> as optional builds rather than core functionality.
>>>>>
>>>>> Steve mentions Wave as one example. The Wave feature is a very nice
>>>>> one, but isn't a core W3C Widget feature. So this might be factored
>>>>> out into an optional module (you could use either the Java/DWR or
>>>>> NodeJS implementations)
>>>>>
>>>>> Another one is JCR support. Currently Wookie is built with both JPA
>>>>> and JCR persistence - should JCR be an optional, pluggable module
>>>>> rather than built-in?
>>>> How do you imagine these optional components being managed? At build time? At runtime?
>>>>
>>>> The holy grail would be auto-configuration at runtime. That is, if a widget indicates it requires a non-core feature Wookie tries to find an implementation, downloads it and installs it (obviously with tight admin controls).
>>>>
>>>> Currently we require features to be added at compile time. This is not very satisfactory. Whilst considering what is/is not core we perhaps ought to think about an extension mechanism too. I'm not suggesting holding up progress on this proposal until we have an extension mechanism ready. Buildtime configuration is fine as a starting point, but having a vision of where we think we are going would be a good idea.
>>> Yes, for feature installs I'd really like to do something better than what we have now. There really is no reason these have to be Java classes, they could just as easily be XML config files loaded at runtime; they were patterned after the Wave feature extension which had a lot more server-side custom code, but that may be better treated as the exception rather than the template.
>>>
>>> So a future model could be feature packages with:
>>>
>>> /myfeature
>>> feature.xml
>>> (various js and css files)
>>>
>>> ... where "feature.xml" is something like:
>>>
>>> <feature>
>>> <name>http://jquerymobile.com</name>
>>> <script src="jquery-1.5.min.js"/>
>>> <script src="jquery.mobile-1.0a4-patched.min.js"/>
>>> <stylesheet src="jquery.mobile-1.0a4.min.css"/>
>>> </feature>
>>>
>>> (which is quite similar to how Shindig manages features)
>
> As this is something I've been meaning to do for ages, I added a ticket for it and went ahead and implemented this. Its quite a bit of refactoring (mostly deletions) but it doesn't look like it breaks any tests.
>
> The new approach loads Features on start by inspecting the /features folder of the local installation and then creating Feature objects for each valid feature.xml file. It holds these in a static List rather than saving them in the database (its only ever going to be a few small objects and doesn't need any query support).
>
> This could be extended relatively easily to include a folder watcher to dynamically install features (similar to widgets) or to dynamically discover and install features if they're needed for a widget (the UC Ross mentioned above) as Feature no longer require any compilation steps.
>
> I'm ready to commit this - I just wanted to give everyone a chance to comment/object before I went ahead.
+ 1
Paul
>
>>>>> Here's my strawman:
>>>> JQuery Mobile is one of many possible frameworks so I'd make this non-core.
>>>>
>>>> As a general guide I would say anything added as a<feature...> in config.xml should be non-core.
>>>>
>>>> I'd also make the widget examples non-core as they will clutter up a live install. It's easy enough to add something to the CLI along the lines of:
>>>>
>>>> wookie installPack widgetSamples
>>>>
>>>> This would get a list of widgets in the "widgetSamples" pack and deploy them to a running instance.
>>>>
>>>> I have an idea for how this "pack" thing could work. It's just a convenience for managing groups of widgets from the command line. If we manage to get runtime deployment of features then these packs could include appropriate features. I'll implement this in the CLI if we head in this direction.
> +1 sounds good, I like the idea of "packs".
>
>>>>> (NB this is just the server, not the connectors sub-project)
>>>> +1 I don't think any of the connectors should be part of core. They are for deployment on other platforms.
>>>>
>>>>> I'm not sure about "services" (effectively, tags) as to whether this
>>>>> really is Wookie core functionality or something a "widget store"
>>>>> like Rave's would add on top, e.g. user-generated tagging.
>>>> I have no idea what they are for, so I guess they are not core for me ;-)
>>>>
>>>> Ross
>
Re: Core vs Non-Core
Posted by Scott Wilson <sc...@gmail.com>.
On 11 May 2011, at 15:37, Scott Wilson wrote:
>
> On 11 May 2011, at 12:29, Scott Wilson wrote:
>> On 11 May 2011, at 12:08, Ross Gardler wrote:
>>
>>> On 11/05/2011 10:21, Scott Wilson wrote:
>>>> Just kicking off a new thread here, as its something we need to think
>>>> about for future direction.
>>>>
>>>> The core purpose of Wookie is to be a W3C Widget server, however it
>>>> also does some "other stuff". At the moment, we build the whole
>>>> project in one go. However, it may be useful to have non-core modules
>>>> as optional builds rather than core functionality.
>>>>
>>>> Steve mentions Wave as one example. The Wave feature is a very nice
>>>> one, but isn't a core W3C Widget feature. So this might be factored
>>>> out into an optional module (you could use either the Java/DWR or
>>>> NodeJS implementations)
>>>>
>>>> Another one is JCR support. Currently Wookie is built with both JPA
>>>> and JCR persistence - should JCR be an optional, pluggable module
>>>> rather than built-in?
>>>
>>> How do you imagine these optional components being managed? At build time? At runtime?
>>>
>>> The holy grail would be auto-configuration at runtime. That is, if a widget indicates it requires a non-core feature Wookie tries to find an implementation, downloads it and installs it (obviously with tight admin controls).
>>>
>>> Currently we require features to be added at compile time. This is not very satisfactory. Whilst considering what is/is not core we perhaps ought to think about an extension mechanism too. I'm not suggesting holding up progress on this proposal until we have an extension mechanism ready. Buildtime configuration is fine as a starting point, but having a vision of where we think we are going would be a good idea.
>>
>> Yes, for feature installs I'd really like to do something better than what we have now. There really is no reason these have to be Java classes, they could just as easily be XML config files loaded at runtime; they were patterned after the Wave feature extension which had a lot more server-side custom code, but that may be better treated as the exception rather than the template.
>>
>> So a future model could be feature packages with:
>>
>> /myfeature
>> feature.xml
>> (various js and css files)
>>
>> ... where "feature.xml" is something like:
>>
>> <feature>
>> <name>http://jquerymobile.com</name>
>> <script src="jquery-1.5.min.js"/>
>> <script src="jquery.mobile-1.0a4-patched.min.js"/>
>> <stylesheet src="jquery.mobile-1.0a4.min.css"/>
>> </feature>
>>
>> (which is quite similar to how Shindig manages features)
As this is something I've been meaning to do for ages, I added a ticket for it and went ahead and implemented this. Its quite a bit of refactoring (mostly deletions) but it doesn't look like it breaks any tests.
The new approach loads Features on start by inspecting the /features folder of the local installation and then creating Feature objects for each valid feature.xml file. It holds these in a static List rather than saving them in the database (its only ever going to be a few small objects and doesn't need any query support).
This could be extended relatively easily to include a folder watcher to dynamically install features (similar to widgets) or to dynamically discover and install features if they're needed for a widget (the UC Ross mentioned above) as Feature no longer require any compilation steps.
I'm ready to commit this - I just wanted to give everyone a chance to comment/object before I went ahead.
>>>> Here's my strawman:
>>>
>>> JQuery Mobile is one of many possible frameworks so I'd make this non-core.
>>>
>>> As a general guide I would say anything added as a <feature...> in config.xml should be non-core.
>>>
>>> I'd also make the widget examples non-core as they will clutter up a live install. It's easy enough to add something to the CLI along the lines of:
>>>
>>> wookie installPack widgetSamples
>>>
>>> This would get a list of widgets in the "widgetSamples" pack and deploy them to a running instance.
>>>
>>> I have an idea for how this "pack" thing could work. It's just a convenience for managing groups of widgets from the command line. If we manage to get runtime deployment of features then these packs could include appropriate features. I'll implement this in the CLI if we head in this direction.
+1 sounds good, I like the idea of "packs".
>>>
>>>> (NB this is just the server, not the connectors sub-project)
>>>
>>> +1 I don't think any of the connectors should be part of core. They are for deployment on other platforms.
>>>
>>>> I'm not sure about "services" (effectively, tags) as to whether this
>>>> really is Wookie core functionality or something a "widget store"
>>>> like Rave's would add on top, e.g. user-generated tagging.
>>>
>>> I have no idea what they are for, so I guess they are not core for me ;-)
>>>
>>> Ross
>>
>
Re: Core vs Non-Core
Posted by Scott Wilson <sc...@gmail.com>.
On 11 May 2011, at 12:29, Scott Wilson wrote:
> On 11 May 2011, at 12:08, Ross Gardler wrote:
>
>> On 11/05/2011 10:21, Scott Wilson wrote:
>>> Just kicking off a new thread here, as its something we need to think
>>> about for future direction.
>>>
>>> The core purpose of Wookie is to be a W3C Widget server, however it
>>> also does some "other stuff". At the moment, we build the whole
>>> project in one go. However, it may be useful to have non-core modules
>>> as optional builds rather than core functionality.
>>>
>>> Steve mentions Wave as one example. The Wave feature is a very nice
>>> one, but isn't a core W3C Widget feature. So this might be factored
>>> out into an optional module (you could use either the Java/DWR or
>>> NodeJS implementations)
>>>
>>> Another one is JCR support. Currently Wookie is built with both JPA
>>> and JCR persistence - should JCR be an optional, pluggable module
>>> rather than built-in?
>>
>> How do you imagine these optional components being managed? At build time? At runtime?
>>
>> The holy grail would be auto-configuration at runtime. That is, if a widget indicates it requires a non-core feature Wookie tries to find an implementation, downloads it and installs it (obviously with tight admin controls).
>>
>> Currently we require features to be added at compile time. This is not very satisfactory. Whilst considering what is/is not core we perhaps ought to think about an extension mechanism too. I'm not suggesting holding up progress on this proposal until we have an extension mechanism ready. Buildtime configuration is fine as a starting point, but having a vision of where we think we are going would be a good idea.
>
> Yes, for feature installs I'd really like to do something better than what we have now. There really is no reason these have to be Java classes, they could just as easily be XML config files loaded at runtime; they were patterned after the Wave feature extension which had a lot more server-side custom code, but that may be better treated as the exception rather than the template.
>
> So a future model could be feature packages with:
>
> /myfeature
> feature.xml
> (various js and css files)
>
> ... where "feature.xml" is something like:
>
> <feature>
> <name>http://jquerymobile.com</name>
> <script src="jquery-1.5.min.js"/>
> <script src="jquery.mobile-1.0a4-patched.min.js"/>
> <stylesheet src="jquery.mobile-1.0a4.min.css"/>
> </feature>
>
> (which is quite similar to how Shindig manages features)
As this is something I've been meaning to do for ages, I added a ticket for it and went ahead and implemented this. Its quite a bit of refactoring (mostly deletions) but it doesn't look like it breaks any tests.
The new approach loads Features on start by inspecting the /features folder of the local installation and then creating Feature objects for each valid feature.xml file. It holds these in a static List rather than saving them in the database (its only ever going to be a few small objects and doesn't need any query support).
This could be extended relatively easily to include a folder watcher to dynamically install features (similar to widgets) or to dynamically discover and install features if they're needed for a widget (the UC Ross mentioned above) as Feature no longer require any compilation steps.
I'm ready to commit this - I just wanted to give everyone a chance to comment/object before I went ahead.
>
>>
>>> Here's my strawman:
>>
>> JQuery Mobile is one of many possible frameworks so I'd make this non-core.
>>
>> As a general guide I would say anything added as a <feature...> in config.xml should be non-core.
>>
>> I'd also make the widget examples non-core as they will clutter up a live install. It's easy enough to add something to the CLI along the lines of:
>>
>> wookie installPack widgetSamples
>>
>> This would get a list of widgets in the "widgetSamples" pack and deploy them to a running instance.
>>
>> I have an idea for how this "pack" thing could work. It's just a convenience for managing groups of widgets from the command line. If we manage to get runtime deployment of features then these packs could include appropriate features. I'll implement this in the CLI if we head in this direction.
>>
>>> (NB this is just the server, not the connectors sub-project)
>>
>> +1 I don't think any of the connectors should be part of core. They are for deployment on other platforms.
>>
>>> I'm not sure about "services" (effectively, tags) as to whether this
>>> really is Wookie core functionality or something a "widget store"
>>> like Rave's would add on top, e.g. user-generated tagging.
>>
>> I have no idea what they are for, so I guess they are not core for me ;-)
>>
>> Ross
>
Re: Core vs Non-Core
Posted by Scott Wilson <sc...@gmail.com>.
On 11 May 2011, at 12:08, Ross Gardler wrote:
> On 11/05/2011 10:21, Scott Wilson wrote:
>> Just kicking off a new thread here, as its something we need to think
>> about for future direction.
>>
>> The core purpose of Wookie is to be a W3C Widget server, however it
>> also does some "other stuff". At the moment, we build the whole
>> project in one go. However, it may be useful to have non-core modules
>> as optional builds rather than core functionality.
>>
>> Steve mentions Wave as one example. The Wave feature is a very nice
>> one, but isn't a core W3C Widget feature. So this might be factored
>> out into an optional module (you could use either the Java/DWR or
>> NodeJS implementations)
>>
>> Another one is JCR support. Currently Wookie is built with both JPA
>> and JCR persistence - should JCR be an optional, pluggable module
>> rather than built-in?
>
> How do you imagine these optional components being managed? At build time? At runtime?
>
> The holy grail would be auto-configuration at runtime. That is, if a widget indicates it requires a non-core feature Wookie tries to find an implementation, downloads it and installs it (obviously with tight admin controls).
>
> Currently we require features to be added at compile time. This is not very satisfactory. Whilst considering what is/is not core we perhaps ought to think about an extension mechanism too. I'm not suggesting holding up progress on this proposal until we have an extension mechanism ready. Buildtime configuration is fine as a starting point, but having a vision of where we think we are going would be a good idea.
Yes, for feature installs I'd really like to do something better than what we have now. There really is no reason these have to be Java classes, they could just as easily be XML config files loaded at runtime; they were patterned after the Wave feature extension which had a lot more server-side custom code, but that may be better treated as the exception rather than the template.
So a future model could be feature packages with:
/myfeature
feature.xml
(various js and css files)
... where "feature.xml" is something like:
<feature>
<name>http://jquerymobile.com</name>
<script src="jquery-1.5.min.js"/>
<script src="jquery.mobile-1.0a4-patched.min.js"/>
<stylesheet src="jquery.mobile-1.0a4.min.css"/>
</feature>
(which is quite similar to how Shindig manages features)
>
>> Here's my strawman:
>
> JQuery Mobile is one of many possible frameworks so I'd make this non-core.
>
> As a general guide I would say anything added as a <feature...> in config.xml should be non-core.
>
> I'd also make the widget examples non-core as they will clutter up a live install. It's easy enough to add something to the CLI along the lines of:
>
> wookie installPack widgetSamples
>
> This would get a list of widgets in the "widgetSamples" pack and deploy them to a running instance.
>
> I have an idea for how this "pack" thing could work. It's just a convenience for managing groups of widgets from the command line. If we manage to get runtime deployment of features then these packs could include appropriate features. I'll implement this in the CLI if we head in this direction.
>
>> (NB this is just the server, not the connectors sub-project)
>
> +1 I don't think any of the connectors should be part of core. They are for deployment on other platforms.
>
>> I'm not sure about "services" (effectively, tags) as to whether this
>> really is Wookie core functionality or something a "widget store"
>> like Rave's would add on top, e.g. user-generated tagging.
>
> I have no idea what they are for, so I guess they are not core for me ;-)
>
> Ross
Re: Core vs Non-Core
Posted by Ross Gardler <rg...@apache.org>.
On 11/05/2011 10:21, Scott Wilson wrote:
> Just kicking off a new thread here, as its something we need to think
> about for future direction.
>
> The core purpose of Wookie is to be a W3C Widget server, however it
> also does some "other stuff". At the moment, we build the whole
> project in one go. However, it may be useful to have non-core modules
> as optional builds rather than core functionality.
>
> Steve mentions Wave as one example. The Wave feature is a very nice
> one, but isn't a core W3C Widget feature. So this might be factored
> out into an optional module (you could use either the Java/DWR or
> NodeJS implementations)
>
> Another one is JCR support. Currently Wookie is built with both JPA
> and JCR persistence - should JCR be an optional, pluggable module
> rather than built-in?
How do you imagine these optional components being managed? At build
time? At runtime?
The holy grail would be auto-configuration at runtime. That is, if a
widget indicates it requires a non-core feature Wookie tries to find an
implementation, downloads it and installs it (obviously with tight admin
controls).
Currently we require features to be added at compile time. This is not
very satisfactory. Whilst considering what is/is not core we perhaps
ought to think about an extension mechanism too. I'm not suggesting
holding up progress on this proposal until we have an extension
mechanism ready. Buildtime configuration is fine as a starting point,
but having a vision of where we think we are going would be a good idea.
> Here's my strawman:
JQuery Mobile is one of many possible frameworks so I'd make this non-core.
As a general guide I would say anything added as a <feature...> in
config.xml should be non-core.
I'd also make the widget examples non-core as they will clutter up a
live install. It's easy enough to add something to the CLI along the
lines of:
wookie installPack widgetSamples
This would get a list of widgets in the "widgetSamples" pack and deploy
them to a running instance.
I have an idea for how this "pack" thing could work. It's just a
convenience for managing groups of widgets from the command line. If we
manage to get runtime deployment of features then these packs could
include appropriate features. I'll implement this in the CLI if we head
in this direction.
> (NB this is just the server, not the connectors sub-project)
+1 I don't think any of the connectors should be part of core. They are
for deployment on other platforms.
> I'm not sure about "services" (effectively, tags) as to whether this
> really is Wookie core functionality or something a "widget store"
> like Rave's would add on top, e.g. user-generated tagging.
I have no idea what they are for, so I guess they are not core for me ;-)
Ross
Core vs Non-Core
Posted by Scott Wilson <sc...@gmail.com>.
Just kicking off a new thread here, as its something we need to think about for future direction.
The core purpose of Wookie is to be a W3C Widget server, however it also does some "other stuff". At the moment, we build the whole project in one go. However, it may be useful to have non-core modules as optional builds rather than core functionality.
Steve mentions Wave as one example. The Wave feature is a very nice one, but isn't a core W3C Widget feature. So this might be factored out into an optional module (you could use either the Java/DWR or NodeJS implementations)
Another one is JCR support. Currently Wookie is built with both JPA and JCR persistence - should JCR be an optional, pluggable module rather than built-in?
Here's my strawman:
Core
====
Parser
Widget API
Widget Instances API
Properties API
WhiteList API
Participants API
Flatpack API
API Key API (todo)
W3C Widget API (metadata, preferences)
W3C Widget Updates
W3C WARP
JPA Persistence
Proxy
JQuery Mobile feature
Basic example widgets
Optional
=======
Wave Feature
oAuth Feature (todo)
JCR Persistence
OpenSocial integration
Scratchpad widgets
(NB this is just the server, not the connectors sub-project)
I'm not sure about "services" (effectively, tags) as to whether this really is Wookie core functionality or something a "widget store" like Rave's would add on top, e.g. user-generated tagging.
S
On 11 May 2011, at 09:25, Steve Lee wrote:
>
>> 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....
Re: [PROPOSAL] Wookie gadget "store" moved to Rave?
Posted by Steve Lee <st...@fullmeasure.co.uk>.
On 10 May 2011 16:17, Ross Gardler <rg...@apache.org> wrote:
> I'd like to propose that some of the code here in Wookie be moved over to
> Apache Rave (Incubating). I feel that it is more likely to be maintained and
> enhanced there. The code in question is present in Wookie in order to make
> Wookie usable, but it is not (IMHO) part of the core objective of Wookie.
>
> If my proposal is accepted it will mean that Wookie would not carry any UI
> code. Instead it would focus on providing a server for the management of
> widget instances. This would not change the headline goal of Wookie ("Apache
> Wookie is a Java server application that allows you to upload and deploy
> widgets for your applications").
As I'm only just engaged I can't comment on the exact details of the
split, but do +1 the broad idea. I'm a keen proponent on the old *NIX
approach of connecting tools that do one thing well. Having an eco
system of such tools in this space should also benefit sustainability.
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.
> 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....
> 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.
> 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
> 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
1: http://straight-street.com/api/