- From: Marcos Caceres <m.caceres@qut.edu.au>
- Date: Thu, 7 Jun 2007 20:17:47 +1000
- To: gene_vayngrib@yahoo.com, "Anne van Kesteren" <annevk@opera.com>
- Cc: public-appformats@w3.org
- Message-ID: <b21a10670706070317s27798327lc63084e4d3ae17cf@mail.gmail.com>
Hi Gene, On 6/6/07, Gene Vayngrib <gene_vayngrib@yahoo.com> wrote: > > 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. agreed. 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. All really good points. These is the kind of implementation feedback we are trying to gather so please keep it coming. 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. I find this idea of the widget:\\ scheme very interesting. However, we need to make sure we have explored what we currently specified and make sure that the problem cannot be solved without specifying something new. Given your implementation experience, maybe you can provide a few more detailed use cases. I'll also start looking in this further next week and make sure it's on the agenda for discussion in future tele-conf. Anne, does Opera have any thoughts on this? 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 ... I'm pretty sure he monitors the WAF work (he made a comment about one of our specs a few weeks ago). If Tim had an issue he would have raised it. 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 <http://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. Hehe, the thought of being chased by the paparazzi has kept me amused for days! Seriously, Gene, this is an open process to capture exactly the use cases you are talking about. Nothing in the spec is set in stone and we rely on people like you to send us feedback. Kind regards, -- Marcos Caceres http://datadriven.com.au
Received on Thursday, 7 June 2007 10:17:54 UTC