- From: Morten Olsen <mol@unwire.com>
- Date: Tue, 22 Jul 2008 10:22:48 +0200
- To: <public-bpwg@w3.org>
Sorry, if I'm posting in the wrong forum/thread. I looked into the widget 1.0 documents a while back, but it lost my focus, as I was actually looking for something more like iGoogle's gadgets, Netvibes widgets, and similar. That is, widgets for inclusion within mobile web pages. Do you know of any initiative moving in that direction? Med venlig hilsen/Best regards Morten Olsen Direct +45 3377 0118 Mobile +45 5122 5049 -----Oprindelig meddelelse----- Fra: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] På vegne af Jo Rabin Sendt: 20. juli 2008 12:08 Til: Sullivan, Bryan Cc: public-bpwg@w3.org Emne: Re: Comments to Widgets 1.0 Requirements Last Call WD Thanks for a comprehensive review, Bryan. My comments on the spec and on Bryan's comments are: a. to note the similarity in use cases between mobile Web browsing and Widgets (in that they are usually targetted, action oriented etc.) and to suggest some reference to the work of the BPWG on Best Practices to see what's translatable - especially for example - the text in BP2 about backing off requests etc. at periods of low activity. b. something about how resources (media etc) need to be compatible with target device types and that resource dependencies need to be spelled out, somehow, somewhere. c. Something about what resources (screen, input device, network, processing, etc.) are needed for effective operation - similar to Bryan's R.21 I think d. R16 Visual Rendering Dimensions - the text states that there must be a way of declaring initial dimensions in pixels, which is potentially at odds with the limited canvas available on many mobile devices, though might be covered under c. above. e. Something about intermittently connected widgets? f. I don't think that we should ask for inclusion of reference to UAPROF as suggested below. Other than that I agree with the general thrust of the comments - but I think we should remember that the document is at last call, so perhaps we should stop short of offering "proposed text". Jo On 18/07/2008 22:53, Sullivan, Bryan wrote: > Hi all, > > Here are my comments to the Widgets 1.0 Requirements Last Call WD. > (_http://www.w3.org/TR/widgets-reqs/_) > > It took me some time to follow up on the action item to inititate this > discussion, but after a thorough review, here are the key points that I > would make at this time re the significance of the widget requirements > to the mobile widget environment. They are looking for feedback before > Aug 1, so if anyone has further comments, they should be sent soon. > > Similar to "*R21./ Security Declarations/*//", the following requirement > should be added: > *R21.**/ Resource Declarations/* > A conforming specification/ must/ specify a means for declaring that the > instantiated widget will have an impact on sensitive device or network > resources, which may impact device performance or the user experience. > > Motivation: > _Security_ <http://www.w3.org/TR/widgets-reqs/>, _current development > practice or industry best-practices_ <http://www.w3.org/TR/widgets-reqs/>. > Rationale: > > To declare the resource requirements of the widget, allowing > the widget user agent to respond accordingly by adjusting > its resource policies and warning the end-user. Example of > resource sensitive services that could require notification > are automated operation involving network access or screen > display, which can impact overall service cost and device > battery life; or persistent storage requirements, which can > affect device performance and reliability of the environment > for other applications. > > Re "*R36.**/ Open Default System Web Browser/*//", I propose a > modification (in red/underline below) > A conforming specification/ SHOULD/ specify a means that allows authors > to open URLs in a browsing contexts outside the widget engine. > > Motivation: > _Current development practice or industry best-practices_ > <http://www.w3.org/TR/widgets-reqs/>. > Rationale: > > To allow author to open a URL in the default system web > browser. For example, in a news aggregator widget, to allow > the end user to navigate to the source of a particular news > item._ __Alternatively, if the widget has ability to > directly present web content, a specific resource may exceed > its capabilities, thus the user can be offered the option of > opening the resource in the default system web browser, > which may have greater capabilities._ > > > _These requirements should be added in 4.5 User Agents:_ > > Rxx./ User-Agent Header/ > > A conforming specification/ must/ specify that the widget/ must/ > identify itself in HTTP requests through the user-agent header, either > as the complete header or as an extension to the default user-agent > header provided by the runtime environment. > > Motivation: > _Current development practice or industry best-practices_ > <http://www.w3.org/TR/widgets-reqs/>, _interoperability_ > <http://www.w3.org/TR/widgets-reqs/>. > Rationale: > > To provide the ability for web servers to determine if it is > possible to serve the widget, or to adapt to the > capabilities or special requirements of the widget. For > example, a widget may attempt to access a service which is > not compatible with the widget, and rather than provide a > possibly incorrect response (which could cause further > issues with the widget), the web server can provide a > specific error response noting the incompatibility. > > > Rxx./ User-Agent Profile Header/ > > A conforming specification/ must/ specify that the widget/ should/ > identify its capabilities in HTTP requests through the Profile header as > described by [CCPPexchange] (_http://www.w3.org/TR/NOTE-CCPPexchange_). > > Motivation: > _Current development practice or industry best-practices_ > <http://www.w3.org/TR/widgets-reqs/>, _interoperability_ > <http://www.w3.org/TR/widgets-reqs/>. > Rationale: > > To provide the ability for web servers to determine if it is > possible to serve the widget, or to adapt to the > capabilities or special requirements of the widget, using > semantic methods based upon detailed capabilities > information provided by the widget. > > Rxx./ Accept Header/ > > A conforming specification/ must/ specify that if a Profile header is > not included in HTTP requests, the widget/ must/ include all supported > MIME types for widget resources in the Accept header. > > > Motivation: > _Current development practice or industry best-practices_ > <http://www.w3.org/TR/widgets-reqs/>, _interoperability_ > <http://www.w3.org/TR/widgets-reqs/>. > Rationale: > > To provide the ability for web servers to determine if it is > possible to serve the widget, or to adapt to the > capabilities or special requirements of the widget, using > semantic methods based upon detailed capabilities > information provided by the widget. > > Rxx./ Default// Use of Runtime Environment Configured Proxy/ > > A conforming specification/ must/ specify that by default, widget HTTP > requests/ must/ be made through the proxy server (if any) configured for > use in HTTP requests issued through the runtime environment or host device. > > > Motivation: > _Security_ <http://www.w3.org/TR/widgets-reqs/>, _current development > practice or industry best-practices_ > <http://www.w3.org/TR/widgets-reqs/>, _Web and offline distribution_ > <http://www.w3.org/TR/widgets-reqs/>, _interoperability_ > <http://www.w3.org/TR/widgets-reqs/>. > Rationale: > > To ensure that widgets can be served in environments for > which an HTTP proxy is required to be used, or be given > value-added services available only through the HTTP proxy. > For example, the runtime environment may be pre-configured > to offer proxy services for all HTTP clients. Unless the > widget has special requirements for use of a different > proxy, the default proxy configuration should be used. > > > Bryan Sullivan | AT&T >
Received on Tuesday, 22 July 2008 08:54:09 UTC