Service Architectures

November 15, 2010

Microsoft Higher Education Briefing

October 13, 2009

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:

  1. 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
  2. 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...

  1. GET /widgets
  2. POST /widgetinstances
  3. POST /participants
  4. 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:

  1. config.xml
  2. icon
  3. HTML start file (doesn't have to be HTML but usually is
  4. 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 :-(

October 01, 2009

Future of Technology in Education (FOTE) 09

Royal Geographical Society, London
2 October 2009

See the FOTE website for the agenda.

October 06, 2008

Future of Web Apps (FOWA), London 2008

Due to some incompatibility between my new EeePC and the venue wifi network this live-blog was undertaken using the soft-keyboard on my iPhone over a 3G connection.  It is therefore both incomplete and somewhat minimal.  That said, I think (hope!) that there is useful information contained within...

For full details about FOWA see the conference schedule and the videos of the presentations.

October 01, 2008

Future of Technology in Education (FOTE)

Imperial College
3 October 2008

Welcome: Tim Bush 09.30 - 09.35
ULCC: David Rippon 09.35 - 09.40
Google: Sam PetersCloud Computing09.40 - 10.00
Virtual-E: Pauline RandallDo I really need a Second Life?10.00 - 10.20
Questions Session One 10.20 - 10.30
Coffee Break 10.30 - 11.00
JANET (UK): Tim MarshallVisions of the Future11.00 - 11.20
BBC Backstage: Ian ForresterWhy portability matters11.20 - 11.40
Yahoo!: James BroadWeb Technologies11.40 - 12.00
ULCC: Philip ButlerPersonalisation12.00 - 12.20
Questions Session Two 12.20 - 12.35
Lunch 12.35 - 14.00
LMN: Maria IlliaShared Services14.00 - 14.20
Ravensbourne: Miles MetcalfeCampus of the Future14.20 - 14.40
Apple: John HickeyBuilding 21st Century Learning Environments14.40 - 15.00
Questions Session Three 15.00 - 15.10
Coffee Break 15.10 – 15.50
RSC South East: Harold FrickerMobile Tech15.50 - 16.10
University of Warwick: Tom AbbottCreativity and media production - moving beyond the lecture theatre16.10 - 16.30
Huddle: Alastair MitchellCollaboration16.30 - 16.50
Questions Session Four 16.50 - 17.00
ULCC: Close 17.00 - 17.05

About eFoundations LiveWire

  • A series of live-blogs from meetings about the Web, cloud infrastructure, linked data, big data, open access, digital libraries, metadata, learning, research, government, online identity, access management and anything else that takes our fancy by by Pete Johnston and Andy Powell.

    All views expressed here are personal.

Powered by TypePad