Re: [widgets] WARP usability issue

On 5/12/11 1:38 PM, timeless wrote:
> 2011/5/12 Marcos Caceres<marcosscaceres@gmail.com>:
>> The following rule is too restrictive in WARP:
>>
>> "If origin is not a valid IRI, *if it has components other than scheme
>> and iauthority*, if it has no host component, or if it has a iuser
>> info component, then this element is in error and the user agent must
>> ignore this element."
>>
>> For the "if it has components other than scheme and iauthority" part,
>> this means that a developer who writes:
>>
>> "http://www.w3.org/"
>>
>> Will have their access request ignored because of the slash. While I
>> was at Opera working on extensions, we noticed in the Opera Extensions
>> catalog that people were doing all sorts of "interesting" things with
>> WARP declarations (e.g., adding "/*" and other things assuming some
>> kind of pattern matching).
>>
>> Anyway, an easy solution is to simply ignore any "/" or simply ignore
>> all but the scheme and iauthority.
>>
>> WDYT?
>
> Shouldn't validators / markets automatically send an error with a
> suggested fix instead of allowing publication?

did you just say "the tools will save us?" :) It's better to avoid 
confusion altogether and make this a bit more liberal, me thinks.

> Could you provide an actual example instance? I'm guessing you can
> point to a public widget and a public server.

I'll try to find something on http://www.operaextensions.com

> As it's origin based, and new, I think it's best to try to push
> producers to create correct content.

This is true, but it's a bit mean to punish developers because of a 
simple slash.

> I really wish that UAs and markets would provide a way for UAs and
> Users to provide feedback about bugs to Authors. On the Web, that's
> impossible, but for things where there are aggregators who collect
> content and require accounts for uploading, it seems like it should be
> a lot easier to manage.

Tools will get there, I'm sure.

> Certainly for addons.mozilla.org, it's possible for site admins to
> give feedback to extension authors about Bugs, Errors, Code Quality,
> and general user feedback.

Opera's system pretty much does the same for extensions.

> For Ovi, there were plans (no idea what happened to them, I presume
> they're still there) to perform automated tests before providing them
> to customers.

Opera checks JS code manually and configs automatically against the P&C 
schema. However, RelaxNG schema checks can't check the level of 
granularity required here (i.e., at the URI specific level).

> For a widget, that should involve trying to install it
> into a user agent, and probably poking a couple of coordinates or
> buttons. It should be possible to recognize errors during testing for
> average cases and give feedback before the widget is made available to
> customers.

The problem is more developers getting put off thinking that the widget 
engine is broken or they go crazy trying to find out what the bug is 
that is not allowing WARP to work.... when it turns out to be just a 
slash.

> Apple's store submission process seems to involve at least some
> automatic and some manual testing. I presume most stores will have
> similar processes. So it seems like this should be something which a
> testing UA should be able to detect and report, and which a
> Store/MarketPlace should be able to manage. UAs should also be able to
> collect anonymous reporting statistics and offer their users the
> option of sending them to their widget vendors.
>
> If a WARP failure is causing the widget to break, then the user is
> likely to be unhappy and the user would probably want to send the
> negative feedback.

This affects devs, instead of users most of the time. WARP simply wont 
work, so users will remain unaffected... that is, unless one engine 
allows "/", as Opera currently does... which will lead to interop fun.

> Having a channel for sending feedback is a good thing, for Widgets,
> for Applications, and for web pages. And getting vendors in the habit
> of handling such feedback by providing basic instances where it is
> likely to happen seems like a good stepping stone to a healthier
> ecosystem.

Agreed. But as I have argued, this issue stings devs long before they 
submit things to an app store. It makes app development just that little 
bit more annoying.

Received on Thursday, 12 May 2011 11:51:27 UTC