CETIS Widgetmeetup October 2009
University of London Student Union
October 2009
Brief notes on the first three talks at the CETIS Widgetmeetup this morning. Note that this meeting was not live-blogged due to lack of a working wifi network at the start of the meeting.
The purpose of this CETIS activity is to:
- work towards deployable widgets for use in VLEs and other Web platforms (Wordpress/ELGG/...) in a plug-and-play form suitable for use by lecturers, and
- having done that, to look at patterns of use and what widgets needed/wanted
Apache Software Foundation
An overview of the ASF by Ross Gardler (OSS Watch)
- 66 top level projects
- plus another 60 incubating projects
- ~2000 code contributors
- 10 years
- 262 members
An Apache Incubator is a place for new projects, each of which must be championed by a member and have 3 mentors.
The incubator leads to a working community (and possibly some working code though the community is seen as much more important).
Incubators can last anywhere between 3 months to 18 months.
At the end of the incubator, IP must be in a state where it is able to be managed properly. That means that when industry gets involved in an ASF project their risks are minimised.
Typical activity story for an ASF member goes something like this...
- they start by checking out what projects/incubators are on offer ("is this stuff any good for me?"). Note that the standardised layout to any project means that it is easy to find issue trackers, code, documentation and so on
- they begin to download and play - they effectively become a user of the project
- they ask questions and discuss topics on the mailing list
- they start start contributing patches (which have to be applied by a current committer)
- they are then invited to become a member of the project - meaning that they can contribute direct to the codebase
Note that all committers can veto code changes by any other committer. Being a committer means that the contribution workflow is smoother but it doesn't really give you any additional rights/ownership.
The whole ASF operation runs for something like $180,000(US) per year.
Lots of the projects are based on standards - their aim is to provider working implementations of standards.
ASF projects are typically quite visible - which is one advantage of going down that route.
Note that new projects can join existing projects as a sub-project of an existing project (but a lightweight incubation period is still required).
Overall ethos is that the community is more important than the code - "community over code"
Wookie and Widgets
A presentation about the Wookie project by Scott Wilson of CETIS.
Scott started by saying why the Wookie project had chosen to implement thru an ASF project.
- clear mechanisms for community support
- clear processes and governance
- clear licencing and legal framework
Wookie is not an acronym
Wookie is an ASF Incubator project.
Wookie is a Java Servlet running in Tomcat or Jetty and offering:
- a REST API
- a Javascript API
- an Admin UI
- Server-side storage
The REST API allows you to get a list of available widgets, to instantiate a new widget instance and to associate participants with that instance.
Typical lifecycle goes like this...
- GET /widgets
- POST /widgetinstances
- POST /participants
- Create an iframe to hold the widget
Plugins are available for LAMS, Moodle, Wordpress and ELGG 1.0 (though the latter two need more work).
A plugin is a bit of code that implements the Wookie lifecycle above.
What widget APIs are supported?
The W3C Widget Object is the default but at the point a new widget is instantiated you can also ask for optional other APIs to be supported - e.g. the Google Wave Gadget API
There has been some integartion with Shindig (which is another ASF incubator for OpenSocial).
Wookie handles getPref/setPref but doesn't handle the Shindig data interface.
Intention to work on inter-widget comms and more support for Bondi/DAP APIs.
What does a widget look like?
Four things:
- config.xml
- icon
- HTML start file (doesn't have to be HTML but usually is
- Javascript code
All of this gets zipped together and the file extension is changed to .wgt.
That's it!
Widget instances can share data but only when they have been instantiated from the same location.
Business model for hosting Wookie widgets not clear yet. Will there be a UK widget 'app' store? Or an EU one?
How do you find widgets?
Widget config.xml file gives you title, description, icon , category (tag) and author. Can browser/search based on these.
Widgets can interact with external services using HTTP (e.g. Ajax) but must do so via a proxy hosted at the Wookie server (which can maintain a white list of allowed services). This prevents widgets opening abitrary connections to remote services.
For more info [email protected]
Google Wave and widgets
Wilbert Kraan (CETIS) gave an overview of Google Wave and the way it handles widgets...
Widgets were originally designed to do one thing for one user - they were typically accessed thru the desktop of a personal computer.
Wookie has changed that - widgets now do one thing for many users - they are typically social in some way.
Google Gadget API provides an alternative platform for doing this kind of thing.
Can fairly easily port Google Wave gadgets into Wookie.
The Wave platform is significantly more complex than Wookie - however, that doesn't necessarkily make it better.
I stopped taking notes when the phrase "wiki widget for wookie and wave" was used. Sorry :-(
Recent Comments