Example use-case for custom widget extensions

Hi All,

First mail to the list: I'm Richard Rodger representing the TSSG:
http://www.tssg.org

I participated in the 2007-10-10 conference call and proposed that we look
at specifying an extension mechanism for widgets. Our specific use-case is
that we want to provide "server-side" capabilities for widgets.

I have therefore put together a sample widget zip file, following my reading
of the current widget spec. Please let me know if you see any mistakes or
mis-interpretations in this zip file (I'm sure there are many!).

The zip file contains an 'ext' folder that contains the custom extension. I
have further proposed that this folder contains sub-folders that are
namespaced, so that multiple extensions might be provided for. Each
subfolder then contains the actual extension files. These files are opaque
to the standard and entirely context-specific custom resouces for a given
widget container.

Marcos has asked me to clarify one aspect of this proposal: what exactly are
we trying to standardize here? The specific items are: 1. the use of an
'ext' folder at the root of the widget zip file, and 2. that the contents of
this folder are name-spaced subfolders per extension.

The reason we propose this, rather than simply loading any additional files
directly using standard JavaScript mechanisms, is that the extensions may
*not* execute on the client. In our use case, the extension actually
executes on a server, accessing a private resource. (in the example, the
server-side code is also JavaScript, but this is simply for the sake of a
consistent programming model; extensions could be Java jars, etc.)

Please note that we are very much in favour of defining a full widget
standard, and that we are not proposing this extension mechanism as a means
to create single-use widgets that are not portable. Extensions can be
ignored by the container. In this case, the widget author should ensure that
the widget degrades gracefully (obviously, an optimistic viewpoint!).

The widget zip file contains a README.txt which goes into the gory details -
appended to this mail.

Best regards,
Richard
 

================
Richard Rodger
FeedHenry
rrodger@tssg.org
353 51 845693



Widget with Extension Example
-----------------------------

This is a widget resource that defines a simple widget that can send SMS
messages. The sending of SMS messages is however performed by a server-side
component. This component is defined in an 'ext' folder within the widget
resource.  Thus, this example proposes defining the 'ext' folder as an
extension point, reserving it in the namespace of the widget resource top
level folder. 

The site hosting this service has previously authenticated the user of the
widget and a HTTP session has been established and maintained using cookies.
A REST-based web service is provided for the client-side widget Javascript
code:
http://widgets.example.com/service/dev/sms?to=123456789&msg=hi+there

This REST API follows the format:
http://<hostname>/service/<domain>/<servicename>[?<params>]

Necessarily, this widget is not portable, and can only function within its
intended host context. The context-specific content is placed within a
context-specific subfolder of the 'ext' folder:
org.tssg.widget.server-0.1
In this way, a namespace convention similar to the Eclipse plugin convention
can be used to isolate context-specific extensions.
A version number is optionally supported as a suffix.


The files within the widget resource are as follows:

- config.xml
    The configuration document. No additional elements are
    proposed.

- index.htm
    The start file. In this example a simple HTML form that
    submits some data using XMLHTTPRequest. Some assumptions
    are made about the valid widget API that this widget can
    use, which are not material to this example.

- ext
    The extension folder. This contains only subfolders following the
    'reversed domain name plus optional version' naming convention.

- ext/org.tssg.widget.server-0.1
    A context-specific extension. When the widget is deployed to
    a host context that recognises this extension name and version,
    the contents of this folder are used to define the extension. The
    meaning of the contents is entirely opaque to the widget standard.

- ext/org.tssg.widget.server-0.1/config.js
    A context-specific configuration file, defining the server-side
    deployment parameters. The attributes are used in an obvious manner.
    ** not a part of the widget standard **

- ext/org.tssg.widget.server-0.1/main.js
    Some context-specific business logic. Presumably the context looks
    for a main.js and expects it to contain some pre-defined methods.
    ** not a part of the widget standard **


The widget operates by making a HTTP call (and thus sets
access='network' in config.xml) to a public REST-based API. The server
providing this API then converts the request into a JavaScript method
call on the server-side widget extention, and returns the content
constructed by the extension.