Re: Example use-case for custom widget extensions

Hi Richard,

On Nov 1, 2007 8:53 PM, Richard Rodger <rrodger@tssg.org> wrote:
> 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.

I'm not sure this needs to be standardized as the spec does not
preclude you from doing 1 or 2. Personally, i don't see much value in
standardizing these but am open to further discussion.

> 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.)

>From what you are saying, the widget is installed on both the
client-side and the server-side? However, I'm not sure I understand
why you are exposing server-side code to the client by including it in
the package? Widgets are mostly built to tap into available online
services; but services are rarely associated exclusively with a
widget.

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

So if I am understanding this correctly, you want to provide a
complete client/server framework for each application (widget)? I
think the client and server code should be separate, so that I can use
a widget to tap into multiple datasources/service provides via a
common or custom API. eg: try http://smsme.com/sms?to=x..., if it
fails then try http://telco.com/sms?to=x.... and so on.

....There is obviously an in-depth discussion we (the mailing list)
need to have about extensibility and the ability to import particular
features and APIs into a widget. This can be a simple as including
<script src="dojo.js"/> to something declaring the use of
system/device specific apis the widget may require to function
<requires api="jsr.locationapi" version="1.0">. I believe Arve raised
something like this at the last working group meeting in Boston.

Kind regards,
Marcos
-- 
Marcos Caceres
http://datadriven.com.au

Received on Monday, 17 December 2007 05:32:56 UTC