(no subject)

Hi Marcos, 
Thank you for your reply and suggestions. 
1) as you said, not part of the spec's charter, is currently not available from any widget platform vendor on mobiles, and is a fairly hard to implement for a widget engine vendor - new common JavaScript Object needs to be defined.

2) event-source is indeed one of the latest choices (see availability in Opera: http://www.subbu.org/weblogs/main/2006/09/server_side_dom_1.html). There are other server push techniques, the oldest and most tested of them all is described on pushlet.com. Yet this approach drains mobile's battery and has many other problems, among them - timeouts by proxies and firewalls, connection restore (spotty wireless coverage), etc.

What I suggested though, requires no API, is a common browser technique since their inception (mailto://), seems to be quite within the "packaging" charter of the spec and is quite easy for vendors to implement. 
The spec would prescribe that widget ID (as defined in config.xml) be used in a URL to point to a widget, like: widget://localhost/widget-id and that the widget engine would perform a "show" operation for this widget. Nothing earth shattering, yet will remove the most painful area with mobile widgets. I would even venture to say - that without this capability the mainstream adoption of mobile widgets is impossible. 

This about it - the spec defines UNIQUE IDENTIFIER for a widget (id element) and yet it is not a URL! Tell that to Tim Berners Lee ... 

For all the goodness the XML brings - aren't we getting carried away focusing on something that is not so important and throwing away the KEY attribute of the Web? I bet spec editors had spent days discussing common manifest format, yet it took us at Lablz.com only 100 minutes to adjust from Apple's Plist to Opera's config.xml format. Yet if Widget URL is (i.e using widget:// protocol) is not defined, there will be no workaround for years. Imagine the headlines: "Web began with URL, but W3C's latest spec decided to break that tradition". Vendors that submitted their current implementations to W3C may not have had the insight, but surely W3C should know better.


Marcos Caceres <m.caceres@qut.edu.au> wrote: 
Hi Gene, 

 Here is a use case - Push mail implemented as widget. Details: widget is running on the mobile phone, SMS message arrives alerting user to some changes. User clicks on a link in URL and a corresponding widget opens and picks up the changes from the Web. This would allow push-mail implemented as widget and many other enterprise scenarios - I can see many uses in CRM, for example. What is important - without widget having its own URL such applications become impossible to create. Please drop me a note if you see ANY workaround based on current Widget spec? 


 The spec only covers covers issues around packaging at this point (because of constraints imposed by the working group charter). Please see requirements 27 in the Widgets Requirements document [1]. Nevertheless, I'll propose a few hypothetical solutions for discussion:  
 
 1. the widget, if allowed by the widget engine, could monitor incoming SMS messages. If an SMS message is from a particular phone number(s) (or contains some other form of identification), the widget could act on it and get the messages from the mail server.  
 
 2. the widget supports HTML5' event-source element [2] and maintains a persistent connection with the server, but without exchanging any data until needed. 

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

[1]  http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-reqs/Overview.html
 [2] http://www.whatwg.org/specs/web-apps/current-work/#the-event-source