Re: [widgets] MWBP WG Comments of Widgets Reqs LC WD, was Re: Request for Comments on Widgets 1.0 Requirements Last Call WD
Hi Bryan We discussed this note from Marcos on the BP call last week [1] (noting that unfortunately you were not there) - in short we agreed that we had made our contribution, as requested, and that as a group we had nothing further to add. We can discuss again on today's call if you like? Jo [1] http://www.w3.org/2008/08/28-bpwg-minutes.html#item10 On 04/09/2008 06:42, Sullivan, Bryan wrote: Hi Marcos, I was starting to respond and thank you for the inclusion in the previous email when I saw this... having been out for vacation etc I did not get a chance to respond earlier. I would like the opportunity to discuss these in detail and support the rationale on the Widgets call. I don't understand the justification for rejection you have described. Overall the requirements represent the core (a limited set) of some pragmatic considerations that will affect the success of widget frameworks in real-world deployments, especially in the mobile device context. As you stated: The main reason for rejecting the feedback was that the proposed requirements were: (a) had limited impact on the actual specs (in normative terms), (b) were overly prescriptive and should really be left as an implementation detail on which implementations can compete, (c) added complexity on either the client side or the server side. (a) Is unclear (which specs are you talking about?). The Widget Requirements spec is the one being commented on, and it is giving direction to conforming specification writers (presumably in W3C and externally). Several of the proposed additions were written in normative terms and meant to be so. (b) In which cases were they overly prescriptive. This seems to me to be a value judgment based upon some criteria. The criteria I use is whether there will be significant negative effects on usability, interoperability, or efficiency if the requirements are not supported. Especially in the mobile case, the normative requirements I proposed can be supported in one or more of those terms. (c) Re complexity, little of value comes free. But overall I don't think any of the proposed normative requirements could reasonably be called complex. I am willing to explain why if given the opportunity. Best regards, Bryan Sullivan | ATT -Original Message- From: Marcos Caceres [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2008 8:14 PM To: Sullivan, Bryan Cc: Arthur Barstow; Mobile Web Best Practices Working Group WG; Web Applications Working Group WG Subject: Re: [widgets] MWBP WG Comments of Widgets Reqs LC WD, was Re: Request for Comments on Widgets 1.0 Requirements Last Call WD Hi Bryan, MWBP WG, FYI, we discussed the MWBP input in last nights teleconf: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0417.html In summary, although I had included most of the requirements proposed by the MWBP WG in the Requirements document, the WebApps WG members overrode my decisions and chose not to include your recommended text into Requirements document. I have now removed the text I added earlier (below) from the Requirements document. The main reason for rejecting the feedback was that the proposed requirements were: (a) had limited impact on the actual specs (in normative terms), (b) were overly prescriptive and should really be left as an implementation detail on which implementations can compete, (c) added complexity on either the client side or the server side. If MWBP WG has concerns with the omission of any proposed requirement, we are happy to discuss anything further to reach consensus before we take the Requirements document to CR. Please note that WebApps is on an extremely tight schedule and we intend to move the Requirements to CR within three weeks; so if we don't hear back from MWBP we will assume that you are in agreement with WebApp's decisions. Having said that, I want to say that the feedback from the MWBP WG was extremely useful because it allowed the WebApps WG to more narrowly focus the architectural aspects of the Widgets 1.0 family of specifications. We want to continue coordinate with members of the MWBP WG on architectural decisions and guidance on best practices for widgets and mobile-based client side web applications. Kind regards, Marcos On Thu, Aug 14, 2008 at 7:45 PM, Marcos Caceres [EMAIL PROTECTED] wrote: Hi Bryan, MWBP WG, On Fri, Aug 1, 2008 at 12:28 PM, Sullivan, Bryan [EMAIL PROTECTED] wrote: Hi Art, The MWBP WG consolidated comments are attached as a HTML document. General comments: Somewhere, perhaps in section 4.2, there should something about how resources (media etc) need to be compatible with the target device types, and that resource dependencies (screen, input device, network, processing, etc.) need to be spelled out. Widgets should be able to express these dependencies in a semantically useful way through a standardized schema and attribute ontologies/vocabularies such as W3C has been working on, e.g. the MWI
Re: [XMLHttpRequest2] comments
On Mon, 11 Aug 2008 00:57:15 +0200, Anne van Kesteren [EMAIL PROTECTED] wrote: For when I next edit this draft (hopefully soon): * Origin header shouldn't point to the origin definition. * Exception codes need to be changed. (See XMLHTttpRequest Level 1.) * Upload notifications should work non same origin as well. * Download notifications should work non same origin as well most likely, even readyState == 2 can work now the processing instruction is gone as far as I can tell. http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ contains edits needed for this, as well as some other clarifications and updates from XMLHttpRequest Level 1. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [XMLHttpRequest2] comments
On Thu, 04 Sep 2008 14:08:02 +0200, Anne van Kesteren [EMAIL PROTECTED] wrote: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ contains edits needed for this, as well as some other clarifications and updates from XMLHttpRequest Level 1. In fact, it might be worth publishing another copy of XMLHttpRequest Level 2 a week after Access Control is released. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [XHR2] upload complete flag
On Mon, 23 Jun 2008 23:17:24 +0200, Olli Pettay [EMAIL PROTECTED] wrote: the draft says that the initial value for upload complete flag is false and then there are several ways to get it set to true. But when is the value set back to false if XHR object is reused? Perhaps '3.5.3 Initiating a Request', right after step 2? I made it step 6 as that also addresses your subsequent comment: On Tue, 24 Jun 2008 11:26:17 +0200, Olli Pettay [EMAIL PROTECTED] wrote: currently per the draft 'abort' and 'error' events are always dispatched to .upload, even if there isn't anything to upload. 'loadstart', 'progress' and 'load' are dispatched only if request entity body is not empty. I think the same restriction should apply to 'abort' and 'error' too. One way to solve this and the upload complete flag handling problem is to set the flag to true in send() if request body is empty. Thanks! For reference, this was in reply to: http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0381.html http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0398.html -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [XHR2] Editorial: OPENED State
On Wed, 23 Apr 2008 12:43:15 +0200, Lachlan Hunt [EMAIL PROTECTED] wrote: This is feedback on the XMLHttpRequest Level 2 draft. In section 3.2 Ready States, the OPENED state is defined, but following those definitions, the spec calls it the OPEN state: The OPEN state has an associated send() flag... Fixed, thanks. (Changed the list by the way from public-webapi to public-webapps.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [Widgets] R21. Resource Declarations. Was RE: Request for Comments on Widgets 1.0 Requirements Last Call WD
Hi Bryan, On Thu, Sep 4, 2008 at 12:06 AM, Sullivan, Bryan [EMAIL PROTECTED] wrote: Hi Marcos, My response is late (the review happened just before vacation and other things...), but here it is: I'm not sure there is a semantically useful way to declare/assess resource dependencies (currently), but that would be the goal. In the meantime simple disclosure is better than the use it if it works for you, otherwise get rid of it approach. At least the user may be able to understand the significance of the disclosure. The examples I provided in the proposal illustrate common resource constraint cases: a) automated operation a.1) network-intensive applications can cost users a lot of money (a critical resource) or drain the device battery (another critical resource). Applications that are designed to operate all the time or in the background (e.g. using Ajax methods) should disclose this so that the user can decide if that's what they want to allow. If possible, the extent of resource usage (frequency of network requests, typical amount of data exchanged) should be disclosed. I fully understand that problem but this depends on the author being honest and making an informed subjective judgment on resource use/abuse of a widget. If I was an author, and I knew that this might mean that some people won't use my app, then I would not include such declarations. In other words, this system is too open to abuse/neglect as the author can simply lie and say that their widget is awesome and perfect (same problem that is seen with CC/PP: I can simply lie, and I'm sure many sites do and there is no legal consequence to lying). My position is that it should be up to the widget user agent to inform the user that a Widget is using up too many resources. I hate to subscribe to technological determinism but, another factor is phones in two years may, for example, come with 20 processors and a built in solar-nuclear-thermal-battery-reactor(tm) and carriers will give everyone unlimited download/bandwidth, so things that are considered resource intensive today, will mean very little tomorrow or ten years from now. a.2) screen updates (e.g. for phonetop widgets) and memory updates (e.g. managing content and variables) can be battery-affecting. Application designers should have some understanding of the typical effect that their applications will have on the devices they target, and make at least useful disclosures of such effects. Again, I still think that this should be handled by widget user agents for the reasons above. b) storage requirements: Web applications may manage local persistent (e.g. flash) storage of content related to the application, and may have a significant impact on the operating memory (e.g. ram) of the device. While user choice in use of the application may significantly affect the storage requirements, the developer should have some understanding of the typical storage requirements. The user could then decide based upon the disclosure, whether they want to allocate a potentially significant amount of storage to this application. The Widget 1.0 Updates specification defines an element that allows the user to be informed of the size of the update they are about to install. Also, a widget user agent could make a HEAD request to a server prior to downloading a widget package to determine its size... though I can see this doesn't exactly cover your use case. Regardless, I still see this as an implementation detail. The real goal as I mentioned would be that a policy management engine could use the declarations to determine if the application would exceed a certain policy (which the user could manage as preferences). Semantic assessment of impact would resolve the variable relative impact problem (or at least reduce it), since the assessor would know how to relate the resource declarations in the context of the host device. I agree, and some limited provisions are in place. But I still think the model is fundamentally flawed if it depends on the author being honest. In the meantime however at least some schema-defined disclosure of resource impacts could be used in a widget installer UI to inform the user of the impacts that the developer is aware of. I think such things are best left to be described by publishers and the end-user community. I.e., publishers already make it possible for users of widgets to leave comments on websites that describe if a widget sucks, uses too many resources, is slow on some particular device, etc... By looking at a typical software download site, I think its pretty clear that users make judgments about whether they download a applications based on an application's popularity and the comments left by others... or from other trusted systems of recommendation (e.g. a friend tells you that an app is really useful)... except for the poor souls who are tricked into downloading spy/malware, which the
Re: [widgets] CCPP in widgets, was Re: Request for Comments on Widgets 1.0 Requirements Last Call WD
Hi Bryan, On Thu, Sep 4, 2008 at 12:18 AM, Sullivan, Bryan [EMAIL PROTECTED] wrote: Hi Marcos, Responding a little late (vacations etc), The CCPP use I've proposed is fairly simple, ala the delivery of a link to a capabilities document that is hosted on a web server, and semantically useful. This is what mobile devices have done for years via the OMA UAProf (using the x-wap-profile header over-the-air, which is sometimes mapped to the profile header in WAP gateways), and while not universal and not without limitations (some of which we are addressing via OMA DPE, W3C MWI/DDWG, and W3C UWA), it represents the only semantically useful way to disclose detailed application characteristics (at least widely deployed and used). The problem, as the working group sees it, is the reliance on RDF (when considering CCPPexchange, which, at the last F2F the group took objection to because that spec is a Note and hence non-normative): RDF puts an unnecessarily heavy burden on anyone on the receiving end of the technology, particularly for something that, as you state, is supposed to be simple. -- Marcos Caceres http://datadriven.com.au
Re: [XMLHttpRequest2] comments
Anne van Kesteren wrote:
For when I next edit this draft (hopefully soon):
* Origin header shouldn't point to the origin definition.
* Exception codes need to be changed. (See XMLHTttpRequest Level 1.)
* Upload notifications should work non same origin as well.
* Download notifications should work non same origin as well most
likely, even readyState == 2 can work now the processing instruction is
gone as far as I can tell.
There are two further features I'd like to see added to XHR, hopefully
in the XHR2 timeframe:
1. A timeout property like the one on microsofts XDR. I haven't looked
into the specifics of XDRs property, but I would think that an
'abort' event should fire as well as readystate transitioning to
something if the timeout is reached.
2. A .responseJSON property. This would return the same thing as the
following code:
if (xhr.readyState != 4) {
return null;
}
return JSON.parse(xhr.responseText);
However there are a few details that can be quibbled about:
a) Should a partial result be returned during readystate 3
b) If the property is gotten multiple times, should that return the
same or a new object every time.
/ Jonas
