Re: [manifest] orientation member

[Scott Wilson]

Hmm. Does this take us back to viewmodes [1]? For example you also have the 
ability on Windows Phone to have the live tiles view, with primary and 
secondary tiles, and both square and wide tiles...

Also it may be necessary to consider where apps are intended not to take over 
the device, but as additional content within another platform, e.g.: OpenSocial 
has 'canvas', 'profile' views, etc. However I think OpenSocial is heading 
towards the option of just using adaptive CSS, along with contextual metadata 
from the container platform via AJAX.

S

[1] http://www.w3.org/TR/view-mode/

On 3 Dec 2013, at 13:47, Mounir Lamouri wrote:

> On Tue, Dec 3, 2013, at 23:32, John Mellor wrote:
>>> I definitely agree with that. Though, we should allow both syntaxes
>>> (array and string).
>>> If we want a more complex system later, we could move to that. For the
>>> moment, I think we should keep it simple.
>> 
>> 
>> It seems an even simpler option would be to simply omit viewport from the
>> manifest for now unless someone can provide a more compelling reason for
>> it
>> being there.
> 
> I think those two options could live side by side. I guess on advantage
> of the manifest is that the orientation can be set once and would apply
> for the entire app.
> 
>> How do the various UAs plan on avoiding a white flash of unpainted page
>> when launching web apps? One potential solution to the white flash might
>> be
>> to delay opening a window for the web app until first paint. In which
>> case,
>> you wouldn't want to rotate the system UI before launching your window
>> anyway...
> 
> Interestingly, Chrome Apps is experimenting that: delaying showing new
> window until the first paint happens to prevent a white flash. It is
> only an experiment because there is the problem of the window not
> showing for a long time if the first paint takes a long time to happen.
> I think doing that on mobile would be easier because there is usually
> one window showing at a time so the user would understand that the app
> is being loaded. I'm a bit digressing though.
> 
> --
> Mounir
> 



PGP.sig
Description: This is a digitally signed message part

Re: HTML as application manifest format

[Scott Wilson]

On 1 Aug 2013, at 18:29, Kornel Lesiński wrote:

> On 1 August 2013 12:44:19 Scott Wilson  wrote:
>> Or you could perhaps use XML. A bit like, er, this:
>> 
>> http://www.w3.org/TR/widgets/
> 
> Hehe ;)
> 
> I'm trying to address two things:
> 
> 1. it's been shown ever and over again that developers on the wild web are 
> really bad at working with strict syntax. HTML, XHTML that won't parse with 
> right mime type, even RSS ended up as a soup.
> 
> Strict manifest will inevitably face the same tension - either single 
> misplaced  JSON comma or XML quote will break the app (and frustrate 
> developers) or browsers and other clients will eventually give up again and 
> accept almost-JSON soup that "works".
> 
> HTML already got past that and deals with real-world mess. Let's not tempt 
> JSON5 :)


I'm quite happy with JSON, XML and HTML we've never had any real issues 
with badly-formed Widget manifests. I don't think there have been many broken 
OpenSocial apps due to markup issues either for that matter. So XML seems OK 
with most web developers treating metadata documents like any other structured 
document. 

JSON on the other hand is a pain to write and fix by hand, even with JsonLint. 

However, the argument has been strongly put in favour of JSON by our friends at 
Mozilla, whereas I'm firmly +0 on this one.

> 
> 2. Pave the cow paths. We already define web apps using meta tags, including 
> bunch of Apple's tags for web apps ("added to home screen" kind).
> 
> Meta is a well-understood existing mechanism that works. Everybody building 
> web apps creates and references HTML pages with metatags all the time.
> 
> Another very important aspect of it is that it lowers the learning curve a 
> lot.
> 
> You learn how to add one meta (that's the charset, should be mandatory for 
> every dev). You then learn few more metas for favicons, google, viewport, 
> mobile Safari. You copy&paste them. *Then* you learn how to create common 
> file, and you do it based on whatever you have working already.
> 
> Very easy and gradual.

I think going with meta tags is a very nice, easy way to get started and builds 
on existing habits. 

Another approach is that taken by http://schema.org/ and microdata. In general, 
pretty much everything in the metadata also turns up somewhere in the app html 
so between meta and microdata you've probably got most of the metadata covered.

However, sometimes you just want the metadata without accessing the app itself. 
In which case, having a separate format matters. So you're back to square one 
again!

> 
> OTOH new format, with new names, new structure, no comments in JSON case, new 
> and annoyingly pedantic syntax and separate file from day 1 is jumping on the 
> deep end.

Well, we've had quite a long time to get used to it! Apple Dashboard, 
Konfabulator, Windows Vista Sidebar, OpenSocial, Opera Widget, Apache Wookie... 
and we're still seeing implementations of the existing Widget XML spec in all 
kinds of odd places (vehicle dash, TVs, electronic whiteboards in schools...)

The barriers have largely been the major platforms having an attack of NIH, not 
any inherent technical problems with HTML vs JSON vs XML :)
> 
> It's trivial for us, experienced developers in this forum, to write JSON 
> manifest, but beginners on the web start with  copy&paste and very little 
> knowledge (and that's good! That's a low barrier to entry) so reusing their 
> skills and letting them learn in small increments will help them a lot.
> 
> Also look into the future - if Web Components with  take off 
> you'll have lots of pages importing HTML of jQuery of components.
> HTML import might become natural and logical way of extending pages, and JSON 
> may remain the odd exception.
> 
> -- 
> regards, Kornel

> 
> 



PGP.sig
Description: This is a digitally signed message part

Re: HTML as application manifest format

[Scott Wilson]

Or you could perhaps use XML. A bit like, er, this:

http://www.w3.org/TR/widgets/

On 18 Jul 2013, at 14:57, Kornel Lesiński wrote:

> 
> I'd like to propose using HTML as basis of manifest format, similar in spirit 
> to Web Components imports, e.g.
> 
> 
> 
> and then my-app-definition.html could contain ,  or other 
> elements.
> 
> 
> Rationale:
> 
> * while JSON is wonderful for automatic serialization, it's an annoying 
> format when maintained by hand (and manifest seems static and simple enough 
> to be maintained by hand).
> 
>  - JSON syntax is pedantic about trailing comma. Authors have to be careful 
> when adding new element to end of a list.
> 
>  - JSON does not support comments. Manifest is a central place of an 
> application, so may end up being modified by many team members, and it's 
> useful to comment why certain properties are the way they are, warn which 
> changes will cause breakage (again…), etc.
> 
> * We already have , ,  name="application-name"> that can be reused. Authors already know these and 
> it may be easier to define and understand how  and manifest properties 
> interact.
> 
> * We already have lang & hreflang attributes, so there's no need to invent 
> locales dictionaries.
> 
> * It can be inlined naturally, saving a RTT.
> 
> * It can be mixed with Web Components allowing applications to define 
> everything in one place if they wish to.
> 
> * Simple websites can reuse homepage as their manifest file:  rel=manifest href=/>
> 
> 
> 
> Here's HTMLized example from the spec:
> http://www.w3.org/2012/sysapps/manifest/#example-manifest
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> http://example.org/dev";>
> https://example.org/dev/es-ES";>
> 
> @viewport {
>  min-width: 300px;
>  max-width: 600px;
> }
> 
> 
> 
> 
> 
> 
> 
> 
> 
> When writing this I was surprised how well existing functionality fits (and 
> thus how much "NIH" can be avoided).
> 
> The only bit that didn't seem natural fit was  for permissions, so 
> maybe a better element needs to be invented for it:
> 
> 
> 
> 
> 
> 
> or perhaps made generic:
> 
> 
>  
> 
> 
> 
>  
> 
> 
> -- 
> regards, Kornel
> 



PGP.sig
Description: This is a digitally signed message part

Re: Kickoff application manifest work

[Scott Wilson]

On 19 Jun 2013, at 07:59, Charles McCathie Nevile wrote:

> On Wed, 19 Jun 2013 06:56:13 +0200, Anne van Kesteren  
> wrote:
> 
>> On Tue, May 14, 2013 at 7:47 PM, Marcos Caceres  wrote:
>>> The current proposal can be found here:
>>> http://manifest.sysapps.org/
>> 
>> I wonder to what extent we actually need a manifest. I think it's main
>> benefit might be in grouping a set of pages, but whether that needs to
>> be via a manifest I'm less sure about.
> 
> I think pretty much any mechanism that groups pages *is* a manifest. There 
> are lots of ways to make them, but given that most shipping solutions have 
> converged on something that looks a lot like the W3C widgets manifest format 
> (in XML), or something in JSON that is very similar, it seems reasonable to 
> assume that isn't a bad starting point.

Its certainly been the usual end point, whether its Java's MANIFEST.MF, 
imsmanifest.xml for training content, or container.xml for ePub. 

Given how similar they are it still amazes me how many different ones keep 
being invented.

If I contributed to the app manifest work, it would mainly be to make sure I 
could easily convert them into either Widgets or OpenSocial, whichever is the 
best fit, given Apache has projects implementing both of those specs already.

> 
>> A requirement that keeps coming back for web applications (i.e. those
>> served in a browser over HTTP, such as https://www.twitter.com/ ) is
>> that multiple of them per origin should be supported.
> 
> Yes.

For portals, e.g. Apache Rave, the approach is often to generate per-instance 
origins, e.g. gadget-122423534534.myportal.net/apps/gadgetx, to prevent XSS 
attacks. Rave, Shindig and Wookie all support this.

> 
>> Reasoning for this is simplicity of deploying new applications and to
>> some extent to reduce the number of DNS queries for a suite of
>> applications.
> 
>> Downside of that approach is increased attack surface for a suite
>> applications
> 
> Can you please expand on that?
> 
>> and no trivial boundary between them (given a URL it's not
>> clear to which application it belongs).
> 
> Well, it is true that a given URL might not be able to say what application 
> it belongs to. But then, it may not need to, or even be desirable. To take 
> silly examples, images rarely know what pages they are part of and scripts 
> often don't. That seems to be a feature, not a bug.
> 
>> Navigation Controller solves the grouping of a set of pages using an
>> origin plus wildcard matching for a set of URLs, although as currently
>> proposed a subset of those URLs might be something else altogether
>> again, without much declarative control.
>> 
>> For event pages/workers you'll want something similar. To identify
>> what a URL's associated event page/worker is.
>> 
>> It might be though that maybe we should put the boundary for
>> applications on the web on the origin level. It would certainly be
>> extremely convenient and allow for a whole bunch of simplifications.
> 
> Yeah, but the price of enforcing origin-based restrictions on the Web is that 
> we break a lot of the "web"-ness. While there are security reasons for doing 
> so in many cases, I think the platform loses each time we build such a 
> restriction. The purpose of things like CORS is to reduce that cost compared 
> to the simplified case of a rigid same-origin policy, and I think that's a 
> pretty good thing.
> 
> just 2 kopecks
> 
> chaals
> 
> -- 
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
>  cha...@yandex-team.ru Find more at http://yandex.com
> 



PGP.sig
Description: This is a digitally signed message part

Re: [widgets] Does anyone still care about Widget Updates?

[Scott Wilson]

On 14 May 2013, at 15:00, Marcos Caceres wrote:

> 
> 
> On Tuesday, 14 May 2013 at 14:32, Arthur Barstow wrote:
> 
>> Scott indicated [1] Wookie implemented Widget Updates and Chaals 
>> indicated [2] he would followup with Opera but I couldn't find a 
>> response from them in the list archive.
>> 
>> Do we have two (complete?) implementations of the spec? Opera, Richard?
>> 
>> It's not clear to me if we should drop this spec (i.e. publish as a WG 
>> Note) or if there are sufficient resource commitments to continue to 
>> advance it along the REC track.
>> 
>> Marcos - what is the status of the test suite 
>> ? (The 
>> Implementation Report doesn't look good 
>> .)
>> 
>> -AB
>> 
>> [1] 
>> 
>> [2] 
>> 
>> 
> 
> Unless someone else wants to take this, I suggest we just publish as a note. 

Well, we implemented it and it works, but I'd be fine with it being published 
as a Note.

> 
> 
> --
> Marcos Caceres
> 
> 
> 
> 
> 



PGP.sig
Description: This is a digitally signed message part

Re: [widgets] Does anyone still care about Widget Updates?

[Scott Wilson]

On 20 Oct 2012, at 13:12, Arthur Barstow wrote:

> For various reasons, a Candidate Recommendation of Widget Updates was never 
> published, although the CfC to do so passed and the ED is prepared as such 
> [widget-updates].
> 
> Since no one has raised this as an issue, I would like feedback on what we 
> should do with this spec. The main options are: 1) to stop work (and publish 
> a WG Note); 2) to move forward with the CR.
> 
> I don'tthink it makes much sense to move the spec to CR if we do not have  
> commitments for at least two independent implementations of the CR. 
> Therefore, Implementors should please speak up if they willcommit to 
> implementing this CR.

Its implemented in Apache Wookie from version 0.13.

> 
> -Thanks, AB
> 
> [widget-updates] 
> 
>  Original Message 
> Subject:  CfC: publish Candidate Recommendation of Widget Updates; 
> deadline May 2
> Resent-Date:  Thu, 26 Apr 2012 16:42:00 +
> Resent-From:  
> Date: Thu, 26 Apr 2012 12:41:34 -0400
> From: ext Arthur Barstow 
> To:   public-webapps 
> CC:   
> 
> 
> 
> The comment deadline for the Widget Updates LCWD ended April 19. No
> comments were submitted for that document so this is a Call for
> Consensus to publish a Candidate Recommendation of the spec using the LC
> as the basis .
> 
> The Exit Criteria for the CR will be the same as that used for the other
> widget specs, namely that two or more implementations must pass each
> test case.
> 
> This CfC satisfies: a) the group's requirement to "record the group's
> decision to request advancement" to CR; and b) "General Requirements for
> Advancement on the Recommendation Track" as defined in the Process Document:
> 
> http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs
> 
> Positive response is preferred and encouraged and silence will be
> considered as agreeing with the proposal. The deadline for comments is
> May 2 and all comments should be sent to public-webapps at w3.org.
> 
> -Thanks, AB
> 
> 
> 
> 
> 
> 

Re: CfC: publish Widgets P&C as a "Proposed Edited Recommendation"; deadline August 28

[Scott Wilson]

On 21 Aug 2012, at 13:20, Arthur Barstow wrote:

> Marcos would like to publish a "Proposed Edited Recommendation" [PER] of the 
> Widget Packaging and XML Configuration spec [REC] to incorporate the spec's 
> errata and this is a Call for Consensus to do so.
> 
> The [Errata] has already been reflected in the [Proposed-PER] (see [Diff]) 
> and it includes a new title of "Packaged Web Apps (Widgets) - Packaging and 
> XML Configuration (Second Edition)".
> 
> Please send all comments regarding this CfC to the public-webapps@w3.org mail 
> list by August 28 and note silence will be considered as agreement with the 
> proposal. If you support this CfC, a positive response is preferred and 
> encouraged.

+1 on the new name, I like it.

Just one grammatical nit in the Abstract - there is an extra "as" before 
"commonly":

This specification standardizes a packaging format and metadata for a class of 
software known as commonly as packaged apps or widgets

> 
> -Thanks, AB
> 
> [PER] 
> [REC] 
> [Errata] 
> [Proposed-PER] 
> [Diff] 
> 
> 
> 
> 

Re: [manifest] Is the Webapp Manifest spec ready for FPWD?

[Scott Wilson]

On 6 Jun 2012, at 16:10, Tobie Langel wrote:

> On 6/6/12 5:02 PM, "Marcos Caceres"  wrote:
> 
>> On Wednesday, June 6, 2012 at 2:58 PM, Tobie Langel wrote:
>> 
>>> Absolutely, or:
>>> 
>>> 
>>> 
>>> and combine appcache and config into a single format. The AppCache
>>> manifest format works beautifully in JSON (and I'm sure it would do
>>> equally well in XML). See how the sample manifest files provided in the
>>> HTML5 spec[1] would look like in JSON: https://gist.github.com/2881982
>> 
>> yep, that could also workŠ though I wonder if it's too late to be
>> swapping manifest formats.
> 
> The two manifest formats could very well co-existing. Furthermore, since
> only the structure of the data differs, the AppCache algorithm wouldn't
> need to change.

This seems like a pretty convincing use-case for obtaining web app metadata, 
and extends the existing practices of iOS meta tags and .ico files (both of 
which are kludges in their own way).

The core metadata seems also pretty simple and uncontroversial: 

id
version
shortName
name
description
author (aka developer)
authorEmail 
authorHref (aka developer.url)
content (aka launch_path)
feature (aka required_feature)
license

We then have some sections that may or may not need some more work:

=== Locales and localization ===

This is pretty close to the approach used in Widgets and maps quite nicely, 
including defaultlocale attribute.

=== Icons ===

Responsive images in general are still quite painful to handle, and I know we 
sort of ducked this one in Widgets. There is also divergence even on aspect 
ratios (OpenSocial uses 2:1 rather than square, for example.) There have been 
some discussions on this topic and related areas such as screenshots (cf Native 
Web Apps and PhoneGap) so this one may need more work.

=== Rendering hints (orientation, viewmodes, height, width...) ===

This continues to be a pain, particularly when apps share the screen as in 
Apache Rave, and you need to make them sit nicely with each other. 

The orientation property seem similar to how PhoneGap has used Widgets [1]. 
However in that case it is used to hint to the device which orientations should 
be enabled by the device, rather than set a launch orientation that may 
conflict with the orientation of the user's device.

Likewise fullscreen is something else that has been used as an extension to 
Widgets by PhoneGap.

However I'm not sure how either of these fits with ViewModes, so this needs 
thrashing out.

=== Security (installs_allowed_from...) ===

This is probably the most controversial area, and relates to a more general 
process of app store behaviour; this is also something we considered under the 
general area of "embedding", and so there are other things that may fit such as 
download links for the packaged version of the webapp. It may have to end up in 
its own spec, or be pushed to the web-app-stores CG.

[1] https://build.phonegap.com/docs/config-xml

> 
> --tobie
> 

Re: [manifest] Is the Webapp Manifest spec ready for FPWD?

[Scott Wilson]

On 6 Jun 2012, at 01:10, Arthur Barstow wrote:

> On 5/30/12 2:36 PM, ext Arthur Barstow wrote:
>> What are people's thoughts on whether or not the Quota Management API spec 
>> is ready for First Public Working Draft (FPWD)?
> 
> (Ooops, c&p error above: s/Quota Management/Webapp Manifest/)
> 
>> A "rule of thumb" for FPWD is that the ED's scope should cover most of the 
>> expected functionality although the depth of some functionality may be very 
>> shallow, and it is OK if the ED has some open bugs/issues.
> 
> In addition to the above, one of the side effects of the publication of a 
> FPWD is that it starts the spec's first Call for (patent) Exclusions (see 
> [CfE] for details). Consequently, the FPWD should contain enough information 
> regarding its scope to facilitate a patent search.
> 
> I mention this because Adam (and others) raised concerns the ED "makes some 
> implicit assumptions about the security model". I don't think that concern is 
> necessarily a showstopper for the FPWD. However, such comments indicate to me 
> the spec's scope isn't quite fleshed out yet, at least regarding security 
> considerations. It would be useful for the ED to be more explicit about the 
> concerns that have raised. For example, the ED could contain some type of 
> Issue block and point to this thread.
> 
> I don't recall the group discussing the UCs and requirements the spec 
> addresses. Perhaps it would also be useful to step back a bit and try to get 
> agreement on some high level requirements before proceeding. (Marcos' 
> requirements document for widgets could provide some useful info 
> [Widget-Reqs].)
> 
> WDYT?

Having looked again at this, I think the easiest approach would not be to 
publish WebApp Manifest as is, but simply to publish a new draft of the Widget 
Interface[1] and do a search/replace on "widget" with "webapp". We can then add 
a section on JSON serialization as a manifest media type, and then take each of 
the proposed model extensions from Mozilla on their own merit.

For compatibility with existing Widgets implementations, all you then need is:

window.webapp = window.widget (or vice versa)

> 
> -AB
> 
> [CfE] http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion
> [Widget-Reqs] http://www.w3.org/TR/widgets-reqs/
> 
> 
> 

[1] http://www.w3.org/TR/widgets-apis/

Re: [manifest] Is the Webapp Manifest spec ready for FPWD?

[Scott Wilson]

On 1 Jun 2012, at 12:15, Arthur Barstow wrote:

> On 5/31/12 5:23 PM, ext Adam Barth wrote:
>> Is anyone besides Mozilla interested in implementing this specification?
> 
> I don't recall anyone else committing to an implementation (although it could 
> be a bit early).

I'd be interested in implementing  support for the JSON manifest format in 
Apache Wookie/Apache Rave, but really want this to be properly harmonized with 
the Widgets specs rather than a competing incompatible spec. 

> All - please speak up both on a) Adam's question; and b) the question in the 
> Subject: header.
> 
> -Thanks, AB
> 
> 

Re: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs

[Scott Wilson]

On 27 May 2012, at 22:07, Guilherme Vieira wrote:

> On Sun, May 27, 2012 at 4:53 PM, Scott Wilson 
>  wrote:
> - If its easy to bypass, why bother with it?  (I once wrote a greasemonkey 
> script that let the Chrome Store work on Firefox :)
> 
> What's the problem? If I understood correctly, the feature is important so 
> that users don't end up opening apps with improper devices simply because it 
> would not work fully (as in the case of the Chrome Store being opened on 
> Firefox), or because the app would look completely broken due to not being 
> designed for that screen size, etc.

Sorry, I didn't really make that very clear - in that case Google had created 
an app format specific to Chrome, however with only a few small tweaks they 
could run on anything (i.e. actually work). It just needed a hack to make that 
happen. (I actually converted Chrome installed apps into W3C widgets...)

> If you really want to open just for fun on something else, to see if the app 
> really does not work in a given browser, and things like that... well, you're 
> free to. But we shouldn't let "normal" users end up in such a situation 
> easily, right?

I understand the intention, which is to give web app developers some means of 
steering users away if they are using a device they don't think will work well 
for them using the app. 

On the other hand, this is the web we're talking about. Everything should work 
in any browser. And if it isn't quite as beautiful when scaled up, and is a bit 
cramped when scaled down, thats still far better than nothing at all.

I'm also not sure how this idea is meant to work for users using screen readers 
or other adaptive technologies.

> 
> -- 
> Atenciosamente / Sincerely,
> Guilherme Prá Vieira (a.k.a. "n2liquid")
> 
> STOP ACTA/CISPA: www.youtube.com/watch?v=WJIuYgIvKsc
> 
> 
> 

Re: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs

[Scott Wilson]

On 27 May 2012, at 17:49, Anant Narayanan wrote:

> On 05/27/2012 05:11 AM, Marcos Caceres wrote:
>> On 27/05/2012 12:36, SULLIVAN, BRYAN L wrote:
>>> Re "At install time or when I am browsing apps, how does a server know
>>> my screen resolution? Or is this restriction imposed on by the user
>>> agent?": When browsing apps, the server can easily access the screen
>>> and window DOM attributes.
>> Right, but that requires some communication that is implicit in the
>> spec. I'm trying to figure out what data is leaving my device and going
>> to the server, and why (i.e., what is the expected life cycle model).
>> There is all sorts of things that are implied going on behind the scenes
>> that this spec eludes to (e.g., installation management/sync across
>> devices), and it's good to get a sense of how it all comes together. If
>> it's not clear in the spec, then I have a hard time seeing how multiple
>> user agents will be able behave in an interoperable manner.
> 
> There is no extra data leaving your device. When you visit a store it will 
> probe for your current device capabilities, and the store, at its discretion, 
> can decide whether or not to let the user install an app. There is no 
> enforcement by the User-Agent at install time.
> 
> Synchronization is an interesting problem that we haven't fully tackled 
> head-on yet. So we might need to add some UA enforcement at sync time as 
> opposed to install time.
> 
>>> When installing apps, the installer (browser, app manager, etc) can
>>> provide a warning to the user that the app is designed for use on
>>> larger screens, and may not work properly on this device.
>> Sure, but doesn't that lead to the original complaint that certain
>> developers don't want their application to install at all for PR reasons?
> 
> In combination with installs_allowed_from, some apps can choose to publish 
> only on certain stores with which they have an agreement that users won't be 
> allowed to install apps on devices they weren't designed for. Sure, it would 
> be easy to bypass this since there is no UA enforcement, but this would be 
> limited to a fairly small technical crowd.

Two objections:

- If its metadata intended for web app *stores* wouldn't it make more sense as 
part of the metadata for store submission, rather than an API for browser-type 
UAs? (Once more I'm CCing the web app stores CG...)

- If its easy to bypass, why bother with it?  (I once wrote a greasemonkey 
script that let the Chrome Store work on Firefox :)


> 
> -Anant
> 

Re: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs

[Scott Wilson]

On 27 May 2012, at 17:45, Anant Narayanan wrote:

> On 05/27/2012 01:35 AM, Marcos Caceres wrote:
>> On 26 May 2012, at 18:32, Anant Narayanan  wrote:
>>> The intent for the screen_size parameters is not to let the developer 
>>> enforce a particular screen size or resolution, but rather specify the 
>>> *minimum* width and height required by the app. This means that on a screen 
>>> below the specified size, the app will not function at all.
>> 
>> To make this more clear, maybe call this min_screen_size.
> 
> Well, we haven't received this request from developers explicitly yet, but 
> one can imagine a situation in which a developer makes an app only for mobile 
> phones (Instagram?) and doesn't want users to use it on desktops. Even though 
> it'll technically work, it might look ugly due to scaling. In this case, 
> we'll need a max_screen_size.

However, it would work great on an interactive whiteboard for a purpose the 
original developer hadn't imagined... or could be used from a mobile phone 
projected into 3D space using a digital projector with pixel mapping... 

I think the intended functionality is something along the lines you see in 
Apple's App Store where you get a sense of which apps are designed for 
iphone/ipod and which are intended for the ipad, and which are fine with both. 
That works OK with a limited number of devices, but in a more heterogeneous 
world it breaks down quickly.

I don't know what the answer is, but fixating on screen sizes doesn't feel like 
quite right. Maybe its the best that can be done. 

(We already have some issues with what to do with the Widget width and 
height in Apache Rave we use it for min-width and min-height CSS attributes 
on the widget iFrame container. However on mobile we tend to ignore it and hope 
the widget includes a viewport tag)

>>> I will also note that it is upto the app store to interpret this field 
>>> however they'd like. If they do not want to disallow installs on devices 
>>> that don't meet the developer-specified criteria, that's fine. However, we 
>>> should still convey this information from the developer to the store via 
>>> the manifest.
>> 
>> At install time or when I am browsing apps, how does a server know my screen 
>> resolution? Or is this restriction imposed on by the user agent?
> 
> The same way an app would find out, by feature sniffing. The app store is 
> also presumably a web page or a "native" store, in either case, it should be 
> able to know the characteristics of the current device using standard 
> techniques.
> 
>>> It is unrealistic to assume that all app developers will make a responsive 
>>> design for all possible screen sizes. The tools aren't great and it costs 
>>> time and money. We added this field after we received a request from the 
>>> developer of a popular game that only worked on desktops, but not mobile 
>>> phones (due to size). They wanted to make sure users weren't able to 
>>> install them in places the app wasn't designed for and get a bad impression 
>>> of the company. I think this is really important.
>> 
>> I think that's fine, but as Scott pointed pointed out, user agents have a 
>> history of allowing users to bypass these kinds of restrictions (or users 
>> hack around them). I think this field can only really serve as a warning 
>> that the app might not work as expected.
> 
> Serving as a warning is sufficient, I agree that we will always have some % 
> of users ignore the warning and install it anyway.
> 
> -Anant
> 
> 
> 

Re: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs

[Scott Wilson]

On 25 May 2012, at 17:25, Marcos Caceres wrote:

> 
> 
> On Friday, May 25, 2012 at 4:34 PM, SULLIVAN, BRYAN L wrote:
> 
>> Marcos,  
>> 
>> Re "I thought we had stopped the whole designing for particular screen 
>> sizes, etc. a long time ago.", that may be the still-closely-held goal, but 
>> the reality is that designing for multiple screen sizes (and pixel 
>> densities) is still far from simple. Even with all the tools that have been 
>> developed in CSS and Media Queries.  
>> 
>> So if developers want to claim that they have focused their design on 
>> specific form factors (and presumably tested it thoroughly on them), this 
>> seems like a good thing as it allows them to be more certain that their apps 
>> won't be distributed to users of devices on which they won't work well 
>> (which will negatively impact the developer's reputation, use of the app, 
>> appstore etc), or if distributed to such users, will be clearly identified 
>> as not being designed for those devices.

I think there is a problem here that we can get very mobile and tablet focussed 
- some of our widgets are also designed with interactive whiteboards and TVs in 
mind which may throw off selections based on things like screen size and pixel 
density. 

I can see users ending up doing the whole "spoof the user-agent string" again 
here, as when sites started showing "your browser is not supported" when you 
viewed them with something the developer hadn't considered. 

Perhaps at the store level it would be nice to have some assertions of 
platforms tested by the developer, but that would be something different really 
(perhaps something for the web app stores CG to look at).

>> 
>> Like many of the things we wanted to do in widget manifest structures in 
>> BONDI and WAC, if these get pulled from the plan the only fallback is 
>> developer ecosystem-specific app metadata, which in the end evaporates with 
>> the developer ecosystems, or never achieves widespread use or 
>> interoperability. So the problem is not solved for developers by leaving 
>> these things out of standards, where there is a strong use case.
>> 
> 
> Still sounds to me like "Made for  here>, and best viewed at 800x600" … and look how well that turned out. Even 
> if we don't focus on mobile devices, it seems like a silly requirement as I 
> can just adjust my browser window to whatever size I want (there is no reason 
> to believe I won't be able to do that on future mobile devices). I.e., screen 
> size and application display area are not the same thing and this metadata 
> attribute seems to assume so.
> 
> --  
> Marcos Caceres
> 
> 
> 
> 

Re: App Manifest & API Proposal

[Scott Wilson]

On 14 May 2012, at 18:12, Anant Narayanan wrote:

> Hi Scott,
> 
> Thanks for your comments, more inline.
> 
> On 5/13/12 12:06 PM, Scott Wilson wrote:
>> On 12 May 2012, at 19:02, Anant Narayanan wrote:
>>> Q. Why not simply reuse the widgets spec [2]?
>>> 
>>> A. Aside from naming (we're talking about apps, the word "widget" seems to 
>>> imply an artificial limitation),
>> 
>> To be fair, you can call your implementation anything you want even if it 
>> implements the "Widget" specs. Maybe we could rename the Widget specs 
>> "Widgets, Apps, Gadgets or Whatever" specs.
>> 
>> If you really, really hate the word that much you could decide to call the 
>> TWI widget object "app" instead in your own documentation, and just silently 
>> convert "window.widget" to "window.app" whenever you come across it. To 
>> reciprocate, I could add a line somewhere in Apache Wookie and Apache 
>> Cordova that does the exact opposite. Interoperability FTW!
> 
> I'm trying to understand how building on the widget spec would work in 
> practice. I'm not opposed to it on principle, but we (Mozilla) have chosen 
> not to implement the widget spec in the past, but we have already implemented 
> the JSON manifest and API spec. If we rework this proposal as an extension to 
> the widget spec, does it mean we will have to implement the entirety of the 
> widget spec too?

"Entirety of the widget spec" isn't much - you've done most of it already. If 
you mean would you have to support an XML manifest, or support packaged apps as 
well as "naked" manifests? No, I can't see a reason you would.

Comparing TWI with the proposal, the only things in TWI that are additional are 
shortName, authorEmail, and preferences. Preferences may not make sense for 
Mozilla's implementation - if so, don't use them, or autowire into WebStorage.

> Essentially, I'd like to make both spec independently implementable, even if 
> we chose to extend some objects defined in the widget spec.

> 
>>> and replacing XML with JSON;
>> 
>> No objections to representing the manifest in JSON either. Would a 
>> serialization of The Widget Interface as a JSON manifest file obviate the 
>> need for defining basically the same metadata in a different spec? We can 
>> then just focus on the things that definitely aren't part of existing specs, 
>> such as the security model, installation events, and default orientation, 
>> all of which look like interesting extensions.
> 
> Rich Tibbett from Opera did precisely that, you can see a mapping here: 
> http://people.opera.com/richt/release/specs/manifests/widgets_to_app_manifest.html
> 
> It looks good to me in general, but I'm a little wary of committing to all 
> fields that are valid keys in the XML schema. Is there a way we can take a 
> subset instead?

The spec defines the set of widget metadata. If you only choose to use a subset 
in implementation, thats fine. 

Also, don't worry about the XML - I think the main point of comparison is the 
Widget Interface spec which already maps a subset of the XML manifest 
properties to JS properties that make sense in the browsing context of a 
running widget. 

So manifest properties that only really apply to a packaged widget wouldn't 
necessarily be used in a JSON representation for a hosted widget.

> 
>>> the other fundamental difference is that the widget spec describes packaged 
>>> apps, whereas our manifest describes hosted apps.
>> 
>> Widgets is also used for hosted as well as packaged apps e.g. Apache Wookie 
>> + Apache Rave...
> 
> Ah, that's really good to know; I hadn't come across a widget that was hosted 
> before, but looks like it is possible.
> 
>>> We think hosted apps have several interesting and unique web-like 
>>> properties that are worth retaining. Hosted apps can be made to work 
>>> offline just as well as packaged apps with AppCache (which is in need of 
>>> some improvement, but can be made to work!).
>> 
>> Which are the bits of this proposal that are important for this and which 
>> aren't found in Widgets? Can we add those to the existing specs to fill any 
>> gaps?
> 
> The manifests in the proposal don't have an "id" field, because an app is 
> simply identified by the domain from which the manifest for it was fetched. 
> This is the key difference, but I'll have to look deeper at the Widget spec 
> to see if there are any more.

The id property is optional in widgets anyway.

> 
>>> Packaged apps do have the

Re: App Manifest & API Proposal

[Scott Wilson]

On 12 May 2012, at 19:02, Anant Narayanan wrote:

> Hi everyone,
> 
> I recently joined the webapps working group and I'd like to introduce myself! 
> I work at Mozilla and for the past year or so have been working on our Apps 
> initiative [1]. Our goal has been to make it very easy for developers to 
> build apps using web technologies that can go above and beyond what one might 
> achieve using "native" SDKs on platforms like iOS and Android. We're also 
> trying to make it really easy for users to find and acquire these apps, and 
> use them on any device they happen to own regardless of platform.
> 
> As part of this work we have devised a simple JSON based manifest format to 
> describe an installable web app, in addition to a few DOM APIs to install and 
> manage these apps. We have a working implementation of the entire system in 
> our latest Nightly builds.
> 
> The manifest and corresponding APIs are described in an early draft at:
> http://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html
> 
> We'd like to propose using that draft as the basis for a FPWD on this topic. 
> I look forward to your feedback!
> 
> 
> FAQs
> --
> There are a few questions I anticipate in advance, which I will try to answer 
> here, but we can definitely go in more depth as necessary on the list:
> 
> Q. Why not simply reuse the widgets spec [2]?
> 
> A. Aside from naming (we're talking about apps, the word "widget" seems to 
> imply an artificial limitation),

To be fair, you can call your implementation anything you want even if it 
implements the "Widget" specs. Maybe we could rename the Widget specs "Widgets, 
Apps, Gadgets or Whatever" specs. 

If you really, really hate the word that much you could decide to call the TWI 
widget object "app" instead in your own documentation, and just silently 
convert "window.widget" to "window.app" whenever you come across it. To 
reciprocate, I could add a line somewhere in Apache Wookie and Apache Cordova 
that does the exact opposite. Interoperability FTW!

> and replacing XML with JSON;

No objections to representing the manifest in JSON either. Would a 
serialization of The Widget Interface as a JSON manifest file obviate the need 
for defining basically the same metadata in a different spec? We can then just 
focus on the things that definitely aren't part of existing specs, such as the 
security model, installation events, and default orientation, all of which look 
like interesting extensions.

> the other fundamental difference is that the widget spec describes packaged 
> apps, whereas our manifest describes hosted apps.

Widgets is also used for hosted as well as packaged apps e.g. Apache Wookie + 
Apache Rave...

> We think hosted apps have several interesting and unique web-like properties 
> that are worth retaining. Hosted apps can be made to work offline just as 
> well as packaged apps with AppCache (which is in need of some improvement, 
> but can be made to work!).

Which are the bits of this proposal that are important for this and which 
aren't found in Widgets? Can we add those to the existing specs to fill any 
gaps?

> Packaged apps do have their own advantages though, which we acknowledge, and 
> are open to extending the spec to support both types of apps.

Hmm, that does kind of negate the previous point... but moving on..!

I'm very positive about this proposal and would love to see it merged into 
Widgets:P&C & TWI, with perhaps a separate spec on web app/widget installation 
including the work Mozilla has done on installation APIs and events. 

I'd be interested in implementing those in Apache Wookie, Apache Rave and 
related projects and initiatives that build on them, as web app installation 
and app store APIs are something thats come up in quite a few implementations 
and it would be great to have a spec for that. 

Just don't tie it to another competing manifest format, please!

> 
> Q. Why is the DOM API in the same spec as the manifest?
> 
> A. One success condition for us would be standardize the DOM APIs so that 
> users will be able to visit any app marketplace that publishes web apps 
> conforming to the manifest spec in any browser and be able to install and use 
> them.
> 
> We understand there might be other platforms on which a JS API may not be 
> feasible (for eg: A Java API to install and manage these apps is equally 
> important), but that shouldn't preclude us from standardizing the DOM API in 
> browsers. The manifest and the API go hand-in-hand, as we think each of them 
> is dramatically less useful without the other.
> 
> 
> Q. Why only one app per origin?
> 
> A. We originally placed this restriction for security reasons. In Firefox 
> (and most other browsers), the domain name is the primary security boundary - 
> cookie jars, localStorage, XHRs are all bound to the domain. For supporting 
> multiple apps per domain we would have to do some extra work to ensure that 
> (potentially sensitive) permissions granted to one

Re: Regarding app notification and wake up

[Scott Wilson]

On 9 Mar 2012, at 08:10, Stefan Hakansson LK wrote:

> The webrtc WG has identified that the ability to notify, and possibly wake 
> up, a web application of incoming events is important. This to enable support 
> of use cases such as incoming calls. And in certain scenarios the resource 
> use (e.g. power) is very important.
> 
> However, this kind of functionality is not in scope of the webrtc WG, but 
> seems to belong to the Web Applications WG. So this is a message that the 
> webrtc WG is interested in seeing technology that supports this being 
> developed. We have also noted discussions in Web Apps around use cases for 
> connection-less push: 
>  - 
> especially the third one is very relevant for us.
> 
> Stefan and Harald (chairs) for the webrtc WG.
> 

Could server-sent events[1] meet this requirement?

[1] http://dev.w3.org/html5/eventsource/

Re: Installing web apps

[Scott Wilson]

On 8 Feb 2012, at 10:31, Bronislav Klučka wrote:

> 
> 
> On 8.2.2012 1:06, Jean-Claude Dufourd wrote:
>> On 7/2/12 05:31 , Robin Berjon wrote:
>>> The first problem is that of the security model. A lot of smart people have 
>>> tried to come up with a lot of different solutions here, often involving 
>>> signatures, policies, intricate user interfaces, etc. I think that's all 
>>> massively over-engineered. Once you take into account the fact that the 
>>> number of applications that actually need this level of privilege is only a 
>>> tiny fraction of the whole, you realise that you can just give up on 
>>> privilege policies. These are just regular apps: they have unfettered 
>>> access — period (within the limits of the underlying platform's permissions 
>>> system naturally). They ought to be harder (and unusual) to install, and 
>>> maybe should look different, but that's it. We might want to give them 
>>> strong CSP protection by default to defend against XSS attacks, but that's 
>>> a detail.
>>> 
>> JCD: I strongly disagree with you there, Robin. I do not see why "installed 
>> apps" should have more access. "Normal apps" and "installed apps" should 
>> have the same security model, but "installed apps" may have permanently 
>> remembered security clearances, and that could be the only difference.
>> My proposal is as simplistic as yours, but in the opposite direction. You 
>> are saying "installed apps" should have all rights, I am saying "installed 
>> apps" should obey the exact same security as "normal apps".
>> In your system, it is dangerous to install an app, but it is very simple. In 
>> mine, there is no danger, but it is a bit more work.
>> Having a difference between installed apps and normal apps is actually 
>> counter-productive.
>> Java tried that for applets, and Java is now gone from the web apps stage.
>> Best regards
>> JC
>> 
> 
> Hi
> just let me quote from this thread
> -
> Tim Berners-Lee:
> 
>  There of course places where XHR is used and there is no
>  cross-sitescripting security needed
> 
>  1)  in a browser extension
>  2)  in node.js code trusted apps
> 
> Ian Hickson:
> 
>  These aren't the Web, so they're probably out of scope of the CORS and XHR
>  specs, but Anne can comment if he disagrees.
> -
> 
> you are one step ahead, firt we need to define, what we want, whether we want 
> web platform (remote access to some data and sometimes being able to 
> manipulate those data with very limited set of APIs) or whether we want 
> actual multi-platform application framework with browser as run-time 
> environment, because there is still a lot of missing and there is apparently 
> disagreement about what should be govern by w3c/whatwg. I'm all for the 
> second option: full programming environment. But that is the first here (and 
> with MS extensions to JS APIs in Metro applications...). And without any 
> distinction between whether the app run locally or whether the UI and data 
> are accessed remotely or any possible combination of UI and data access 
> mechanism.
> 
> And the question of granting rights seems to be fairly decided here, 
> everything potentially dangerous has to be granted by user (e.g. FileSystem 
> API, GeoLocation), and if UA can provide more granular way of managing data 
> and rights (not "remove browsing data" and suddenly everything for every page 
> is gone), we can stick with this principle: HTML, CSS, basic JS is fine... 
> anything else must be granted.

Right, and so far we haven't had a generic model for how that is done, instead 
individual specs have had to define it (as in your examples).

WebIntents potentially offers a generic model for apps requesting data while 
keeping the user in the loop, and one that would work both for websites/hosted 
apps/normal apps and widgets/installed apps/system apps. 


> 
> 
> Brona
> 
> 
> 

Re: Installing web apps

[Scott Wilson]

On 1 Feb 2012, at 21:04, Tim Berners-Lee wrote:

> 
> On 2012-02 -01, at 15:23, Marcos Caceres wrote:
> 
>> Hi Tim,  
>> 
>> On Wednesday, 1 February 2012 at 16:42, Tim Berners-Lee wrote:
>> 
>>> Note that when people talk about installation, they often immediately 
>>> discuss
>>> packaging and manifest formats, which will need to be defined,
>> 
>> Um… we have a REC for that, remember?  
> 
> Yes, but I'm specifically trying to avoid the discussion of whether you use
> widgets or manifests or node.js or what.
> 
> Sorry, we have come a long way from my original comment on public-webaps 
> about 
> the same-origin-policy needing a way of letting a script know why the 
> access failed, which lead to Ian H saying that here was no need
> for installation and my saying that there was.  So I was arguing for the need
> for installation, and I am if course aware of widgets.
> 
> I precisely *didn't* want to get into a detail about whether everyone should 
> use
> widgets or will use widgets -- I want to argue for XMLHTTPRequest 
> being designed to be able to be used not only in an untrusted web page,
> but e.g. from an installed widget, or node.js for that matter,
> which means returning a defined error response when the privilege is
> insufficient, instead of faking a network error.
> I've been trying to write code which will work in any of these.

In the Widgets space this is part of:

http://www.w3.org/TR/widgets-access/

Its up to user-agents how they expose these access request policies to the 
user, whether to ask on installation, or on first use etc.

The issue of 'trusted web applications" has also come up before in this context 
also, see Robin's blog post:

http://berjon.com/blog/2011/02/harmful-trust.html

> 
> 
> Tim

[widgets] Widget Interface test cases

[Scott Wilson]

I'm not sure if the Widget Interface spec[1] and test cases[2] agree on the 
semantics of "clear()" storage calls. The Web Storage spec[3] indicates that 
for clear() all items should be removed from the storage array (i.e. deleted), 
however some of the test cases assume that the values of the items are instead 
set to Null:

http://dev.w3.org/2006/waf/widgets-api/Overview.html#ta-ae test "at":

 window.widget.preferences.clear(); 
 if(window.widget.preferences.getItem("protected") === "abc123" || 
window.widget.preferences.getItem("deletable") === null){
(This actually has two errors - it should be && not ||, and the second clause 
should be true if "deletable" is undefined.)

http://dev.w3.org/2006/waf/widgets-api/Overview.html#ta-aa test "au":
  prefs.clear();
  prefs.setItem("test3", "123abc");
   //ask that the test be restarted
  restart();
   }else if(prefs.getItem("test1") === null && 
  prefs.getItem("test2") === 'protected' && 
  prefs.getItem("test3") === '123abc'){
Again, the test should indicate the preference is undefined, not null.

S

[1] http://dev.w3.org/2006/waf/widgets-api/
[2] http://dev.w3.org/2006/waf/widgets-api/test-suite/
[3] http://www.w3.org/TR/webstorage/

Re: Widgets & ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)

[Scott Wilson]

On 16 Sep 2011, at 13:55, Dominique Hazael-Massieux wrote:
> 
>> IMO, keeping them together will lead to confusion. The use cases are
>> different: a widget can embed content that uses ApplicationCache, as
>> well as load in proprietary APIs (e.g., WAC).
> 
> Surely a Web-applicationcached app could also load proprietary APIs. And
> an application cache could also have a widget as part of its list of
> cacheable resources.
> 
>> It can be used for defining other classes of applications and formats
>> (e.g., Opera Extensions).
> 
> I can also imagine using ApplicationCache to do that.

I can imagine using all kinds of other things to do that. 

The point is, I don't want to, I want to use one standard way to do it along 
with all other companies in the space so we have a market, not a whole bunch of 
non-interoperating silos, and have a consistent message for users.

I don't really understand what the point is of putting these things together. 
Other than to annoy Marcos of course :)

> 
> Widgets and ApplicationCache differ in some ways (e.g. the security
> model of widgets is different, widgets currently don't have an origin,
> etc), but I still don't see how they would fundamentally address
> different use cases.
> 
> Dom
> 
> 
> 

Re: [widgets] Implementing the Storage Event for widget preferences

[Scott Wilson]

On 13 Jul 2011, at 16:41, Marcos Caceres wrote:

> On 7/13/11 5:08 PM, Scott Wilson wrote:
>> Hi,
>> 
>> In my attempt to get our conformance level from 97% to 100%, I've been
>> trying to implement the Storage Event requirement for widget.preferences
>> in the Widget API spec [1]. I'm using the following JS code injected
>> into the widget page to raise the event:
>> 
>> [89] var evt = document.createEvent('StorageEvent');
>> [90]
>> evt.initStorageEvent('storage',false,false,key,old_value,new_value,window.location,widget.preferences);
>> [91] window.dispatchEvent(evt);
>> 
>> However, in Safari I get "Test did not run or storage event was never
>> fired."
>> 
>> In Firefox 3.6, I get "Test setItem-fires-event failed by throwing the
>> following exception: [Exception... "Operation is not supported" code:
>> "9" nsresult: "0x80530009 (NS_ERROR_DOM_NOT_SUPPORTED_ERR)" location:
>> "http://localhost:8080/wookie/shared/js/wookie-wrapper.js Line: 89"]"
>> 
>> In Opera 11.50, I get "Test setItem-fires-event failed by throwing the
>> following exception: Error: WRONG_ARGUMENTS_ERR"
>> 
>> Any pointers?
> 
> What is widget.preferences implementing?

Well, it "implements" the Widget preferences spec - but I guess in typeof terms 
its an Object.

[widgets] Implementing the Storage Event for widget preferences

[Scott Wilson]

Hi,

In my attempt to get our conformance level from 97% to 100%, I've been trying 
to implement the Storage Event requirement for widget.preferences in the Widget 
API spec [1]. I'm using the following JS code injected into the widget page to 
raise the event:

 [89] var evt = document.createEvent('StorageEvent');
 [90] 
evt.initStorageEvent('storage',false,false,key,old_value,new_value,window.location,widget.preferences);
 [91] window.dispatchEvent(evt);

However, in Safari I get "Test did not run or storage event was never fired."

In Firefox 3.6, I get "Test setItem-fires-event failed by throwing the 
following exception: [Exception... "Operation is not supported" code: "9" 
nsresult: "0x80530009 (NS_ERROR_DOM_NOT_SUPPORTED_ERR)" location: 
"http://localhost:8080/wookie/shared/js/wookie-wrapper.js Line: 89"]"

In Opera 11.50, I get "Test setItem-fires-event failed by throwing the 
following exception: Error: WRONG_ARGUMENTS_ERR"

Any pointers?

Thanks,

S

[1] http://www.w3.org/TR/widgets-apis/

Re: [webstorage] Plan to move the spec to Last Call Working Draft

[Scott Wilson]

On 30 Jun 2011, at 14:55, Arthur Barstow wrote:

> Given the lack of support for stopping work on Web Storage [1], I'd let to 
> get consensus on the plan to move it to Last Call Working Draft.
> 
> Currently there are two open bugs:
> 
> 1. Bug 12111: "spec for Storage object getItem(key) method does not match 
> implementation behavior". PLH created a version of the spec that addresses 
> this bug [12111-fix].

> 
> 2. Bug 13020: "No user agent will implement the storage mutex so this passage 
> does not reflect reality".
> 
> There are different opinions on the priority of Web Storage ...
> 
> * Web Storage is a low priority and the Editor will get to it when he gets to 
> it
> 
> * Web Storage is a high priority because the lack of a LCWD will block at 
> least the Widget Interface spec from progressing on the Rec track
> 
> There are various options on what to do next, including:
> 
> 1. Fix 12111 and 13020 and move Web Storage to LCWD

+1

> 
> 2. Leave Web Storage as is and eventually implementations will match the spec
> 
> 3. Do #1 in one version of the spec and keep #2 as a separate version of the 
> spec (e.g. L1 and L2).
> 
> Comments on these options are welcome.
> 
> If you prefer #1, please indicate if you are willing to create a fix/patch 
> for bug 13020.

Yes.

> 
> -AB
> 
> [1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1110.html
> [12111] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111
> [12111-fix] http://www.w3.org/2011/06/Web%20Storage.html
> [13020] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13020
> 
> 

Re: [Widgets] Mozilla open apps

[Scott Wilson]

On 29 Jun 2011, at 12:34, Marcos Caceres wrote:

> On Wed, Jun 29, 2011 at 12:08 PM, Charles McCathieNevile
>  wrote:
>> On Tue, 28 Jun 2011 20:17:38 +0200, Scott Wilson
>>  wrote:
>> 
>>> I think Bruce Lawson was dropping a big hint the other day to look again
>>> at the questions Mike posed a long while ago! I know there was discussion at
>>> the time, but I think both initiatives have moved on somewhat so its worth
>>> returning to.
>> 
>> I agree that it is worth returning to.
>> 
>> The TPAC meeting in Santa Clara might be a good chance to sit down in the
>> same place and talk about it as well as email, which is generally a better
>> way to clarify what the issues are but not always the most effective way to
>> solve the hard ones.
>> 
>> Are people likely to be in the Bay Area in the first week of November, and
>> prepared to spend a bit of time discussing this?
> 
> I think it is a great idea. However, there is a lot we can do in the
> *6 months* in between! :)
> 
> These specs should be at REC by November. As the Last Call period for
> P&C, Dig Sig, and API finished yesterday, Artb will send out a mail
> today to begin the PR preparation process for most of the Widget
> specs: WARP and View Modes have met their CR exit criteria, and are
> also ready to be moved to PR and REC. This means that by September,
> these specs will be in PR. And REC in November.
> 
> If we are going to do anything about widgets, it needs to happen
> sooner rather than later.

Mike may want to correct me here, but I couldn't see anything in MOWA that 
would require changes to the Widgets specifications that are currently on 
track. 

I think we can get there via a Note on applying Widget specs in the case of Web 
Apps (packaged and non-packaged), or further spec work (perhaps under the FSW 
banner) to cover things like web app store interoperability and trust. 

> 
> -- 
> Marcos Caceres
> http://datadriven.com.au

Re: [Widgets] Mozilla open apps

[Scott Wilson]

I think Bruce Lawson was dropping a big hint the other day to look again at the 
questions Mike posed a long while ago! I know there was discussion at the time, 
but I think both initiatives have moved on somewhat so its worth returning to.

On 20 Oct 2010, at 19:40, Mike Hanson wrote:

 Note replying here to an old post for context

> Hi there -
> 
> I can speak for the technical aspects of the Apps project and relay feedback 
> as needed.
> 
> We had looked at the Widget Packaging spec earlier in the project and had 
> steered away from it because we were focused on the "in-browser/live URL" use 
> case.  But as we added icons, names, descriptions, and whatnot, we've 
> converged back on something close to Widget Packaging.
> 
> So... I think, as you note, it's worth making the effort -- I propose that we 
> try to figure out how to make the Widget spec fit our current use case, and, 
> if it doesn't, see if we can find a small number of deltas that get us there.
> 
> I'll try to summarize the differences here:
> 
> In-Browser/"live content" usage
> Our goal is to encompass "in-browser" application usage, where some subset of 
> normal web browsing activity is identified as an "app".  
> 
> This means that we need to identify some subset of the URL value space that 
> "belongs" to an app.  Our current approach (which is close to the one 
> proposed by Google [1]) is to identify a URL set (Google allows regexes; we 
> propose domain-matching with a path prefix).  Google proposes allowing a 
> carve-out of "browsable URLs", which can be visited without leaving the app, 
> presumably for federated login.
> 
> Specifically, this means that the content element would need to be replaced 
> or augmented with some sort of app_urls or somesuch.  It also seems like the 
> HTML5 App Cache proposal is addressing the same problem space as content; is 
> there some way to harmonize all of this?  If we get this right we can perhaps 
> get a smooth continuum from "live web site" to "dedicated brower instance" to 
> "widget".
> 
> We also intend to experiment with embedding URLs for service endpoints -- for 
> example, a cross-document postMessage sink.  I don't see an element that we 
> could adopt for that purpose yet; perhaps we could propose an extension.

Looking at Mozilla Open Web Application (MOWA) and Widgets today, I don't see a 
big issue here. If you host a Widget manifest with or without a  
element it would behave rather like a MOWA manifest. E.g., if there is no 
 or no {launch_path: blah} you would use the default. In 
the case of MOWA this is the origin of the manifest, in the case of Widgets it 
would be /index.html (etc).

I guess there isn't any guidance on "naked" Widget manifests as such, but I've 
always assumed this would be possible/supported. If we write a Note on "web 
apps" we could put it there.

> 
> Per-application metadata repository and access API
> We propose that the "application repository" maintain some metadata that is 
> in addition to, and along side, the manifest.  Specifically, an authorization 
> URL, signature, installation location and date, and perhaps an update URL.
> 
> The gist of our approach (and the part that is really new, I think) is that 
> JavaScript running in some web context can ask, "has the user installed an 
> app for my domain?"   And then, further, "if the user has an authorization 
> URL for my domain, load it now".
> 
> You could try to use the Widget API for this, but the trust model isn't 
> exactly right.  Our intent is that the user has a trust relationship with a 
> store or directory, and has a less trusted relationship with the app; the app 
> does not discover the authorization URL, for example.  In our thinking this 
> implies that there is a "app repository" object that has a couple methods; 
> AFAIK there isn't an equivalent object that has the "list of all installed 
> widgets" in the spec.  Am I missing something?

This looks quite similar to the REST APIs that Apache Wookie exposes, though we 
don't make them available within the Widget context itself. I think its quite 
specific to a type of Widget store model rather than the Widgets/Apps 
themselves, and it does seem a bit strange to access them via the running app 
script context rather than addressing the server directly. In any case, there 
is useful functionality in MOWA (e.g. the "install" function could download the 
actual .wgt, rather like the Opera Widgets site, or be overridden with 
implementation-specific behaviour) but it doesn't feel like its either within 
the scope of Widgets itself nor a blocker for MOWA using Widgets. Indeed, the 
MOWA APIs themselves could be exposed as s, or directly injected into 
applications regardless if running on a MOWA-capable Widget server.

> 
> XML vs. JSON
> Cultural nit: many web developers have trouble with complex XML encodings.  
> It's frustrating, but true.  Would the specification of a JSON dialect be 
> amenable, or is it that a no

Re: [widget] technology/specification name

[Scott Wilson]

On 24 Jun 2011, at 10:41, Marcos Caceres wrote:

> On Fri, Jun 24, 2011 at 11:08 AM, Rich Tibbett  wrote:
>> Marcos Caceres wrote:
>>> 
>>> On Fri, Jun 24, 2011 at 1:28 AM, Charles Pritchard
>>>  wrote:
 
 One issue which comes up is that widget is also used in ARIA to describe
 ui elements.
 
 I suspect we'll see apps used ubiquitously; widget seems to e reserved to
 early experiments in linked apps; apps via iframe.
 
 Like many on this thread, I don't have a strong objection against the
 name. I rather appreciate the thread, it's bringing out more distinctions 
 as
 to what we're talking about and targeting.
 
>>> 
>>> Lets just change it to Packaged Web Apps.
>>> 
>> 
>> Agreed.
>> 
>> I'd couple that with the short-hand term 'web package'.
> 
> We would just be changing the title of the documents.
> It's not like we are changing the  element or the widget
> interface. This is just a repaint of the bikeshed from off white to
> mother of perl.
> 
> I think this is probably the 1000th time we have had this naming
> discussion over the last 5 years. Hopefully, if we do change stuff as
> we go to REC, it will be the last.


OK, that sounds a bit confusing.

Rather than change the Widgets: P&C spec, how about create a new Note on 
"Packaged Web Apps" that references the W3C Widgets family of specifications as 
the recommended set of specifications for realizing the various "packaged web 
app" UCs?

That way we can talk about "W3C Packaged Web Apps" without invalidating any 
references to the individual Widget specifications.

(This is sort of like sticking a mother-of-pearl facade onto the front of the 
bikeshed rather than repainting it)

> 
> -- 
> Marcos Caceres
> http://datadriven.com.au

Re: [widget] technology/specification name

[Scott Wilson]

Part of the issue is that its a fairly generic technology that can be applied 
to areas including:

- Browser extensions
- Installable web apps 
- Desktop widgets
- Site gadgets
- TV/STB widgets
- Mobile webapps

I think the name "widgets" came from the heritage of Opera Widgets, Nokia 
Widgets, Apple Dashboard Widgets (etc). Personally I don't think its all that 
bad as a name, but I don't feel especially attached to it either. If there is a 
better option, lets go for it.

On the other hand, if there are barriers to adoption other than branding, lets 
address them. Unfortunately, I suspect a fair amount of it is just NIH syndrome.

S

On 23 Jun 2011, at 17:26, Dave Raggett wrote:

> In the webinos project [1] we are using installed vs hosted web apps.
> 
> On 23/06/11 15:58, Karl Dubost wrote:
>> I do not want to start a name bikeshedding.
>> The name doesn't bother me so far, but I have seen that comment again and 
>> again.
>> 
>> On Thu, 23 Jun 2011 14:06:24 GMT
>> In Bruce Lawson’s personal site : Installable web apps and 
>> interoperability
>> At 
>> http://www.brucelawson.co.uk/2011/installable-web-apps-and-interoperability/
>> 
>> Installable apps (in W3C parlance, Widgets – which
>> is a terrible name) allow authors to write apps
>> using HTML(5), CSS, JavaScript, SVG etc, and
>> package them up into a glorified Zip file with
>> some configuration details which can then be
>> installed on a computer.
>> 
>> It seems that "extensions" or "addons" would be more cognitively connected 
>> with Web developers.
>> 
>> y'know, so terrible is the W3C “Widgets” name
>> that I didn't even think it referred to the
>> same thing as Chrome’s apps, et al.
>> — http://twitter.com/nevali/status/83866541388603392
> 
> [1] http://webinos.org/
> 
> -- 
> Dave Raggett  http://www.w3.org/People/Raggett
> 
> 

Re: [webstorage] origin security check

[Scott Wilson]

On 14 Jun 2011, at 06:28, Marcos Caceres wrote:

> On Monday, June 13, 2011, Ian Hickson  wrote:
>> On Mon, 13 Jun 2011, Marcos Caceres wrote:
>>> 
>>> I thought maybe I could get away with:
>>> 
>>> "When getting or setting the preferences attribute, if the origin of a
>>> widget instance is mutable (e.g., if the user agent allows
>>> document.domain to be dynamically changed), then the user agent must
>>> perform the object initialization steps of [Web Storage] substituting
>>> the preferences attribute for the localStorage attribute where
>>> appropriate."
>>> 
>>> But maybe I'll just do a copy and paste and just replace the appropriate
>>> bits of text.
>> 
>> I guess that could work.
>> 
>> By the way, how are you resolving the multiple-thread problem here? (Since
>> you're introducing a new API, it presumably doesn't have to have the same
>> bug as the localStorage API, where we're stuck for legacy reasons and are
>> basically forced to either have a cross-thread blocking API or a racy API,
>> depending on how it's implemented, both of which suck.)
> 
> We are not solving it:(
> 
> As widgets run as a single process, each instance in a unique origin,
> don't share data/cache with browser tabs/windows or other widgets,
> this issue does not come up much... At least no one has complained to
> me about it.

We've seen clients setting the same preference in different threads resulting 
in a consistency problem, however we basically go with the view that its 
something we just deal with - i.e. its not guaranteed to be consistent but we 
make best effort. In general use in a widget context its not going to be 
frequent or critical - we only come across it in a testing context by creating 
duplicate views of a widget instance, showing them alongside each other, which 
is a pretty pointless thing for a user to do.

> 
> 
> 
>> --
>> Ian Hickson   U+1047E)\._.,--,'``.fL
>> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>> 
> 
> -- 
> Marcos Caceres
> http://datadriven.com.au
> 

Re: [widgets] P&C test suite fixes

[Scott Wilson]

On 13 May 2011, at 16:06, Marcos Caceres wrote:

> Hi,
> 
> I changed dlocuse00 to use the language tag "xx" instead of "en-gb"...
> 
> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-defaultlocale-usage/000/ta-de-000.wgt


I've tried this one but don't really understand it. I thought that 
defaultLocale would be used as a "last resort" in cases where there is no 
non-localized content available - so for this:

http://www.w3.org/ns/widgets"; 
defaultlocale="x-w3c-test">
dlocuse00

Instantiating the widget and making a default call for / resolves to:

/index.html

which exists in the widget package; and not:

/locales/x-w3c-test/index.html

though maybe I'm not understanding the expected behaviour?

S


> 
> And dlocuse01 was pointing to the wrong file! Try:
> 
> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-defaultlocale-usage/001/dlocuse01.wgt
> 
> I have updated the test description document, including a bunch of typos.
> 
> 
> Kind regards,
> Marcos
> 

[widgets] P&C Test suite: default locale

[Scott Wilson]

I'm having a go at implementing the defaultlocale attribute, but have a problem 
with the test cases - these all use defaultlocale="x-w3c-test". 

The problem is that this is a private use code, and so converts to 
"und-x-w3c-test" during processing. By default I don't even allow BCP 
extensions in the first place either, and so if I make some exception code just 
for this language tag its not really a very good test of conformance more 
generally.

Would it be possible to change the tests to use a real language tag instead?

S

Re: [widgets]

[Scott Wilson]

On 24 May 2011, at 15:17, Marcos Caceres wrote:

> On 5/23/11 10:18 AM, Scott Wilson wrote:
>> Within the education vertical, the IMS consortium created a basic "launch" 
>> protocol for widget-like applications including user information and custom 
>> parameters [1] and we created a shim for using it with Apache Wookie [2]. So 
>> certainly a tractable area; If anything the IMS spec could work with far 
>> fewer parameters.
> 
> agreed. Looks IMS looks far too complicated.
> 
> In most cases, all you want is:
> 
> $ engine -x y -z 123 some.wgt
> 
> Or
> 
> http://xxx/some.wgt?x=y&z=123


In Wookie its:

POST /widgetinstances 
widgetid=somewidgetIRI
apikey=myapikey
userid=scott
shareddatakey=mypage
locale=en 

... which creates an instance and returns the instance URL and metadata for 
rendering.

We also have another resource endpoint for setting preferences:

POST /properties
instance id
propertyname
propertyvalue

So this would support the use case, but in two API calls rather than a single 
POST.

(see: http://incubator.apache.org/wookie/wookie-rest-api.html)

> 
>> That said I don't think it would be difficult to construct a simple launch 
>> process for the STB that mapped parameters like programme/channel context 
>> information onto one of Preferences or Feature Parameters.
>> 
>> [1] http://www.imsglobal.org/lti/blti/bltiv1p0/ltiBLTIimgv1p0.html
>> [2] http://code.google.com/p/basiclti4wookie/
>> 
>> On 23 May 2011, at 00:51, Doug Schepers wrote:
>> 
>>> Hi, Richard-
>>> 
>>> Depending on your timeline, this could be a v2 feature...
>>> 
>>> Any interest in following that up?
>>> 
>>> Regards-
>>> -Doug
>>> 
>>> Marcos Caceres wrote (on 5/20/11 3:47 PM):
>>>> On 5/20/11 5:19 PM, Richard Felton wrote:
>>>>> Hi,
>>>>> 
>>>>> Hopefully this is the right place to ask this question.
>>>>> 
>>>>> I'm looking at the possibility of using W3C widgets as a web-app
>>>>> mechanism on an IP connected set-top box. I've had a look through the
>>>>> specifications available and I can't see a way to pass launch parameters
>>>>> to a widget. Is this possible or has it been ruled out for good reason?
>>>>> 
>>>>> For example, if I want to write a branded media player application (in a
>>>>> widget) it'd be useful if I could allow the set-top box user interface
>>>>> to pass the identifier of the programme to be played into the widget.
>>>>> Effectively I'm looking for a way for a widget to specify something
>>>>> similar to command line options so that the launching entity can control
>>>>> the state the widget starts up in.
>>>> 
>>>> There is no standardized means to do this today, I'm afraid. However,
>>>> you could either pre-generate the widget to contain such information, or
>>>> acquire it from from the set top box through a http request. Another
>>>> means might be to create a proprietary:
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
> 

Re: [widgets]

[Scott Wilson]

Within the education vertical, the IMS consortium created a basic "launch" 
protocol for widget-like applications including user information and custom 
parameters [1] and we created a shim for using it with Apache Wookie [2]. So 
certainly a tractable area; If anything the IMS spec could work with far fewer 
parameters.

That said I don't think it would be difficult to construct a simple launch 
process for the STB that mapped parameters like programme/channel context 
information onto one of Preferences or Feature Parameters.

[1] http://www.imsglobal.org/lti/blti/bltiv1p0/ltiBLTIimgv1p0.html
[2] http://code.google.com/p/basiclti4wookie/

On 23 May 2011, at 00:51, Doug Schepers wrote:

> Hi, Richard-
> 
> Depending on your timeline, this could be a v2 feature...
> 
> Any interest in following that up?
> 
> Regards-
> -Doug
> 
> Marcos Caceres wrote (on 5/20/11 3:47 PM):
>> On 5/20/11 5:19 PM, Richard Felton wrote:
>>> Hi,
>>> 
>>> Hopefully this is the right place to ask this question.
>>> 
>>> I'm looking at the possibility of using W3C widgets as a web-app
>>> mechanism on an IP connected set-top box. I've had a look through the
>>> specifications available and I can't see a way to pass launch parameters
>>> to a widget. Is this possible or has it been ruled out for good reason?
>>> 
>>> For example, if I want to write a branded media player application (in a
>>> widget) it'd be useful if I could allow the set-top box user interface
>>> to pass the identifier of the programme to be played into the widget.
>>> Effectively I'm looking for a way for a widget to specify something
>>> similar to command line options so that the launching entity can control
>>> the state the widget starts up in.
>> 
>> There is no standardized means to do this today, I'm afraid. However,
>> you could either pre-generate the widget to contain such information, or
>> acquire it from from the set top box through a http request. Another
>> means might be to create a proprietary :
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 

Re: [widgets]

[Scott Wilson]

Hi Richard,

On 20 May 2011, at 16:19, Richard Felton wrote:

> Hi,
> 
> Hopefully this is the right place to ask this question.
> 
> I'm looking at the possibility of using W3C widgets as a web-app mechanism on 
> an IP connected set-top box. I've had a look through the specifications 
> available and I can't see a way to pass launch parameters to a widget. Is 
> this possible or has it been ruled out for good reason?
> 
> For example, if I want to write a branded media player application (in a 
> widget)  it'd be useful if I could allow the set-top box user interface to 
> pass the identifier of the programme to be played into the widget. 
> Effectively I'm looking for a way for a widget to specify something similar 
> to command line options so that the launching entity can control the state 
> the widget starts up in.

It depends on the widget engine and what APIs it exposes. 

For example, when a web application requests a widget instance from Apache 
Wookie[1], you can also set any of its preference values using a REST API call. 

Other engines could offer a widget launch protocol that allows setting 
preferences in the launch parameters.

S

[1] http://incubator.apache.org/wookie/
 
> 
> Regards,
> 
> Richard.

[widgets] Widget Updates test case issue: ta-pr-005

[Scott Wilson]

This test case states:

"Tests that update-info element's version attribute should have a value higher 
than current version for the widget to be updated. The widget is not updated or 
replaced."

However, in the specification itself, there is no condition that the potential 
update version has to be "higher" than that of the incumbent widget, only 
different [1].

S

[1] 
http://dev.w3.org/2006/waf/widgets-updates/#verifying-and-installing-an-update

Re: [widgets] WARP usability issue

[Scott Wilson]

On 12 May 2011, at 13:43, timeless wrote:

> On Thu, May 12, 2011 at 2:50 PM, Marcos Caceres
>  wrote:
>> did you just say "the tools will save us?" :)
> 
> i did,  did!
> 
>> It's better to avoid confusion
>> altogether and make this a bit more liberal, me thinks.
> 
> i think we risk people thinking that paths are allowed and meaningful.
> i'd rather avoid that confusion up front.

I've seen WARP origins with paths in them already.

>> This is true, but it's a bit mean to punish developers because of a simple
>> slash.
> 
> there's a path to the dark side, and i think you're approaching it :).
> 
>> Tools will get there, I'm sure.
> 
> :)
> 
>> Opera's system pretty much does the same for extensions.
> 
> :)
> 
>> 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).
> 
> It seems like a WARP validator (whatever that might be) should be able
> to handle this if it's able to see the content in the first place.
> 
>> 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.
> 
> Sounds like UAs need an authoring/debugging mode with better error reporting.

I'd be tempted to just strip off any trailing slashes on import. Actually I 
might do that for all path components in a WARP origin rather than throw an 
error.

>> 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.
> 
> Grr. please don't do that, slippery slopes like this / races to the
> bottom are really unfair to everyone else.
> 
>> 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.
> 
> Sounds like a problem that a little education (samples, FAQ/gotchas),
> and a little UA reporting for authors help should address. Ideally UAs
> should be able to recognize when an author is authoring (perhaps
> because the widget is unsigned?)
> 
> I really don't think relaxing the syntax is the right path forward.
> 

Re: [widgets] Widget Updates tests?

[Scott Wilson]

On 28 Apr 2011, at 14:11, Hari Kumar G wrote:

> On Thu, 28 Apr 2011 14:57:20 +0200, Scott Wilson 
>  wrote:
> 
> ...
>> 
>> One more thing, the widget at:
>> 
>> http://people.opera.com/harig/wupdres/resources/pass.wgt
>> 
>> ... isn't valid as its not well formed - there should be ?> at end of line 1.
>> 
> 
> Fixed.

Fantastic - thanks.

Just one more thing...

 Test ta-processing2-14, "Tests that update-info element's src attribute need 
to be valid, else it is ignored. The widget is not updated or replaced."

However, the value to fail with is "fail.wgt" which ought to be interpreted as 
a relative URL, in which case the expected result would be to turn this into:

http://people.opera.com/harig/wupdres/resources/fail.wgt

Which is valid.

So, the test needs to have a different value to be an invalid src attribute.

S

> 
> -- 
> Hari Kumar G
> Quality Assurance
> Opera Software

Re: [widgets] Widget Updates tests?

[Scott Wilson]

On 28 Apr 2011, at 12:19, Rich Tibbett wrote:

> Scott Wilson wrote:
>> Right, I've done some basic work on the tests in Apache Wookie - most of 
>> them seem to work OK so far; I need to do interactive testing next - I've 
>> tested processing the update element in config.xml and acquiring and 
>> validating the UDD, but not actually processing the updates.
>> 
>> However there are some issues I've found so far:
>> 
>> Test ta-preparation1-8
>> This fails to parse as a valid widget as the XML isn't well-formed
>> 
>> Test ta-processing2-3
>> I get a content type of text/html when getting the UDD
>> 
>> Test ta-processing2-7
>> I get an error of the UDD XML not being well-formed
>> 
>> Test ta-processing2-9
>> I get a content type of text/html when getting the UDD
> 
> All the above tests have been fixed.

Great, thanks!

> 
>> 
>> Test ta-processing2-16
>> We throw a UDD parse exception when a UDD has a relative URL for the src 
>> attribute, but the test seems to assume you just silently fail to update the 
>> widget?
> 
> The processing in this case was underspecified in the spec. I've updated the 
> specification to allow for relative URLs to be included in the 'src' 
> attribute. The resolution system for relative URL src attributes to absolute 
> valid IRIs has also been included in the spec (i.e. resolve relative URLs 
> relative to the UDDs IRI).
> 
> Relative URLs are not allowed in the update-description element of a widget's 
> config.xml.
> 
> We've therefore replaced ta-processing2-16 test with a test to check that the 
> resolution of src attribute relative URLs is working correctly.

Makes sense.

> 
>> 
>> Test ta-processing2-19
>> I get a content type of text/html when getting the UDD
>> 
>> Test ta-processing2-20
>> I get a content type of text/html when getting the UDD
>> 
> 
> These tests have been fixed.
> 
> HTH, Rich

Its a big help, thanks.

One more thing, the widget at:

http://people.opera.com/harig/wupdres/resources/pass.wgt

... isn't valid as its not well formed - there should be ?> at end of line 1.


S

Re: [widgets] Widget Updates tests?

[Scott Wilson]

Right, I've done some basic work on the tests in Apache Wookie - most of them 
seem to work OK so far; I need to do interactive testing next - I've tested 
processing the update element in config.xml and acquiring and validating the 
UDD, but not actually processing the updates.

However there are some issues I've found so far:

Test ta-preparation1-8
This fails to parse as a valid widget as the XML isn't well-formed

Test ta-processing2-3
I get a content type of text/html when getting the UDD

Test ta-processing2-7
I get an error of the UDD XML not being well-formed

Test ta-processing2-9
I get a content type of text/html when getting the UDD

Test ta-processing2-16
We throw a UDD parse exception when a UDD has a relative URL for the src 
attribute, but the test seems to assume you just silently fail to update the 
widget?

Test ta-processing2-19
I get a content type of text/html when getting the UDD

Test ta-processing2-20
I get a content type of text/html when getting the UDD


S

On 26 Apr 2011, at 16:59, Rich Tibbett wrote:

> Hi Scott,
> 
> On 28.03.2011 at 15:59, Scott Wilson wrote:
>> 
>> Are there any tests available - even informal ones - for the Widget 
>> Updates[1] spec?
>> 
> 
> We've just uploaded the Widget Updates test suite to the CVS repository.
> 
> The Widgets Updates test suite is available here:
> 
> http://dev.w3.org/2006/waf/widgets-updates/test-suite/
> 
> Individual test cases are available at 
> http://dev.w3.org/2006/waf/widgets-updates/test-suite/test-cases/
> 
> Once we have some implementer feedback on the tests we'll go ahead and 
> populate the Widget Updates implementation report in the usual way:
> 
> http://dev.w3.org/2006/waf/widgets-updates/imp-report/
> 
> If you have any feedback or questions just let us know.
> 
> - Rich
> 
>> 
>> [1] http://www.w3.org/TR/widgets-updates/

Re: [widgets] Widget Updates tests?

[Scott Wilson]

On 26 Apr 2011, at 16:59, Rich Tibbett wrote:

> Hi Scott,
> 
> On 28.03.2011 at 15:59, Scott Wilson wrote:
>> 
>> Are there any tests available - even informal ones - for the Widget 
>> Updates[1] spec?
>> 
> 
> We've just uploaded the Widget Updates test suite to the CVS repository.
> 
> The Widgets Updates test suite is available here:
> 
> http://dev.w3.org/2006/waf/widgets-updates/test-suite/
> 
> Individual test cases are available at 
> http://dev.w3.org/2006/waf/widgets-updates/test-suite/test-cases/
> 
> Once we have some implementer feedback on the tests we'll go ahead and 
> populate the Widget Updates implementation report in the usual way:
> 
> http://dev.w3.org/2006/waf/widgets-updates/imp-report/
> 
> If you have any feedback or questions just let us know.

Thanks Rich! 

I'll get to work on the Widget Updates implementation in Apache Wookie now :-)

> 
> - Rich
> 
>> 
>> [1] http://www.w3.org/TR/widgets-updates/

Re: [widgets] localizing author

[Scott Wilson]

On 8 Apr 2011, at 09:42, Charles McCathieNevile wrote:

> Hi,

> I just realised that I actually localise my own name in certain languages 
> (most particularly to ensure that I get my preferred transliterations when I 
> am publishing). But I cannot do that in config.xml. Likewise, I would like to 
> localise the href for me which would be possible if I could localise the 
> author element but isn't at the moment.

Many of my Chinese colleagues also have an "English name" as well as a Chinese 
name; the English name isn't a translation or transcription of the Chinese 
name, its often completely different.

I can also see the point of localized hrefs - again I have colleagues who may 
want to point to a Facebook profile page in English, and a RenRen one in 
Chinese.

I guess the workaround at present is to use the element to do something like

王密 (Michelle Wang)

... which is not completely ideal as you don't get different hrefs.

> I don't now if this is too late for the current version, in which case please 
> log it as an issue for the future.
> Changing it to allow localisation would mean a change to the schema - and at 
> least to Opera's implementation. I haven't yet checked (I only realised I 
> want to do this but it isn't allowed today) whether we have any preference 
> for making that change now or later.

I presume the change would be to make Author multiple with xml:lang. I think a 
risk is that developers might reasonably interpret this as meaning "one 
 element for each person" rather than "one  element per 
locale". 


> 
> cheers
> 
> Chaals
> 
> -- 
> Charles McCathieNevile  Opera Software, Standards Group
>je parle français -- hablo español -- jeg lærer norsk
> http://my.opera.com/chaals   Try Opera: http://www.opera.com
> 

Re: [widgets] possible test errors for The Widget Interface?

[Scott Wilson]

OK, having read both P&C and TWI next to each other I can see now how this can 
work - there is just a slight confusion in the two specs with regard to default 
text direction.

Basically, P&C's rules for text direction always return a direction (default: 
LTR) whereas the TWI rules - and test cases - assume the default is no 
direction (Null). So by using the P&C algorithm to generate the properties, I 
ended up failing a lot of the TWI tests as all my properties had a "dir" value. 
To make both sets of tests pass, I have to set the default as Null rather than 
LTR despite what P&C says - this is fine as the browser treats no-direction as 
LTR by default anyway.

Not a big problem to work around, but it did trip me up and does seem 
inconsistent.


On 4 Apr 2011, at 10:57, Scott Wilson wrote:

> I'm having problems passing test i18nlro06 for the Widget Interface test 
> suite [1].
> 
> The test expects a value of: 
> "\u05DD\u05E4\u05DC\u202D\u05D7\u05DC\u202C\u05E7" for the Name attribute;
> 
> Following the localizable strings algorithm[2], we actually return: 
> "\u202A\u05DD\u05E4\u05DC\u202D\u05D7\u05DC\u202C\u05E7\u202C"
> 
> This may also apply to test i18nlro07.
> 
> -S
> 
> [1] http://dev.w3.org/2006/waf/widgets-api/test-suite/
> [2] http://dev.w3.org/2006/waf/widgets-api/#getting-localizable-strings-

[widgets] possible test errors for The Widget Interface?

[Scott Wilson]

I'm having problems passing test i18nlro06 for the Widget Interface test suite 
[1].

The test expects a value of: "\u05DD\u05E4\u05DC\u202D\u05D7\u05DC\u202C\u05E7" 
for the Name attribute;

Following the localizable strings algorithm[2], we actually return: 
"\u202A\u05DD\u05E4\u05DC\u202D\u05D7\u05DC\u202C\u05E7\u202C"

This may also apply to test i18nlro07.

-S

[1] http://dev.w3.org/2006/waf/widgets-api/test-suite/
[2] http://dev.w3.org/2006/waf/widgets-api/#getting-localizable-strings-

[widgets] Widget Updates tests?

[Scott Wilson]

Hi everyone,

Are there any tests available - even informal ones - for the Widget Updates[1] 
spec?

Cheers,

S

[1] http://www.w3.org/TR/widgets-updates/

Re: Overview of W3C technologies for mobile Web applications

[Scott Wilson]

Hi Dom,

This is really helpful - thanks for making this! 

(I'm also working on some EU research projects, and I keep mentioning W3C specs 
which no-one else has heard of, so this is a good resource to point researchers 
and developers at.)

I think a 3-monthly update would also be worth doing given the pace of new spec 
work going on.

S

On 24 Feb 2011, at 15:03, Dominique Hazael-Massieux wrote:

> (bcc to public-html and public-device-apis; please follow-up on
> public-webapps)
> 
> Hi,
> 
> As part of a European research project I'm involved in [1], I've
> compiled a report on the existing technologies in development (or in
> discussion) at W3C for building Web applications and that are
> particularly relevant on mobile devices:
> http://www.w3.org/2011/02/mobile-web-app-state.html
> 
> It is meant as a picture of the current state as of today, based on my
> own (necessarily limited) knowledge of the specifications and their
> current implementations.
> 
> I'm very much looking for feedback on the document, the mistakes it most
> probably contains, its overall organization, its usefulness.
> 
> I can also look into moving it in a place where a larger community could
> edit it (dvcs.w3.org, or www.w3.org/wiki/ for instance) if anyone is
> interested in contributing.
> 
> I'll likely publish regular updates to the document (e.g. every 3
> months?), esp. if it helps sufficiently many people to understand our
> current ongoing activities in this space.
> 
> Thanks,
> 
> Dom
> 
> 1. http://mobiwebapp.eu/
> 
> 
> 

Re: Widgets - WARP, Widgets Updates and Digital Signatures

[Scott Wilson]

On 8 Feb 2011, at 18:48, Marcos Caceres wrote:

> Hi Tim,
> In [1], it sounds to me like you are after W3C Widgets [2]; we have almost 
> finished standardizing them so no need to wait.

You might also find this post useful:

http://scottbw.wordpress.com/2011/02/08/web-apps-a-snapshot-of-the-standards-landscape/

> 
> You can play with them today in Opera [3] and a bunch of other great runtimes 
> [4].
> 
> Kind regards,
> Marcos
> 
> [1] http://lists.w3.org/Archives/Public/www-tag/2011Feb/0078.html
> [2] http://dev.w3.org/2006/waf/widgets/
> [3] http://www.opera.com/download/
> [4] http://www.w3.org/2008/webapps/wiki/WidgetImplementation


> On 2/8/11 6:37 PM, Nathan wrote:
>> Nathan wrote:
>>> Marcos Caceres wrote:
 On 9/16/10 6:10 PM, Nathan wrote:
> Marcos Caceres wrote:
>> As above. I thought that was what we (Web Apps WG - Widgets) have been
>> doing for the last 5 years?
> 
> Maybe I've missed part of the specifications - are you telling me
> that I
> can package up an HTML,CSS,JS based application as per the widgets
> specification, include a WARP, Digital Signature, set the view-mode to
> windowed and that this will run as is, in the main browser context of
> the main browser vendors (Firefox, Safari, Opera, Chrome, IE etc)?
 
 Ah! ok. I get it now. No, that won't work right now (actually, that's
 how we run them in our development environment for testing purposes
 :) ). But that is trivial and no one has really asked for that.
>>> 
>>> Good to know, and you can consider me as asking for it!
>>> 
 I'm still a bit lost as to what the use case is?
>> 
>> following up, see "Web Apps -- requirements for installation and
>> management" from TimBL:
>> 
>> http://lists.w3.org/Archives/Public/www-tag/2011Feb/0078.html
>> 
>> Best,
>> 
>> Nathan
> 
> -- 
> Marcos Caceres
> Opera Software
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [widgets] New Widget Update Types: Kill Switch and Patch

[Scott Wilson]

On 7 Feb 2011, at 14:22, Marcos Caceres wrote:

> On Mon, Feb 7, 2011 at 1:46 PM, Scott Wilson
>  wrote:
>> I really like the Kill Switch/EOL idea and having a "type" attribute to 
>> specify it, but I'm concerned that the Patch type could be a bit more 
>> problematic to get consistently implemented.
>> 
> 
> Understood. What concerns are you having or what interop issues do you 
> foresee?

Principally the handling of the various update states, rollbacks after failing 
to apply patches, problems with multiple-version-spanning patch updates that 
kind of thing.

Also when we unpack a widget and ready it, its no longer exactly the same as 
the input .wgt so we'd have to apply the patch against the originally imported 
package rather than the actual installed instance and then load it again or the 
patch won't take - so we may as well update the whole package anyway.

Its not a bad idea in principle, but potentially a lot of code to save a few kb 
of downloading.

> -- 
> Marcos Caceres
> Opera Software ASA, http://www.opera.com/
> http://datadriven.com.au



smime.p7s
Description: S/MIME cryptographic signature

Re: [widgets] New Widget Update Types: Kill Switch and Patch

[Scott Wilson]

I really like the Kill Switch/EOL idea and having a "type" attribute to specify 
it, but I'm concerned that the Patch type could be a bit more problematic to 
get consistently implemented.

On 6 Feb 2011, at 17:15, Marcos Caceres wrote:

> Opera would like to discuss adding the following attribute to the update-info 
> element of the widget Updates specification: "type".
> 
> Details below...
> 
> == The type attribute==
> 
> The type attribute serves to inform the user of the type of update that will 
> potentially be performed on a widget. The type range from "update", "patch", 
> or "eol" (end of life/kill switch). For backwards compatibility, when the 
> attribute is missing or in error, the default behavior is to behave as an 
> update - like we currently do today (see Update below).
> 
> http://www.w3.org/ns/widgets";
> type="update|patch|eol"/>
> 
> 
> === Update ==
> An update is a completely new version of the widget, where all the files of 
> the widget are replaced with the files contained in update. Effectively, an 
> update causes all the files in an installed widget to be deleted, and a new 
> widget to be installed in its place. Only the widget's id and Storage data 
> remain from one version to the next. This is the current and default behavior.
> 
> Requirement: when the type attribute is missing, the user agent assumes this 
> an "update". Updates are always applied when the mime type of an update is 
> application/widget.
> 
> Example:
> http://www.w3.org/ns/widgets";
> src = "https://w.example.com/2.1/RC/app.wgt";
> version = "2.0"
>type="update">
>  
>Totally awesome new version!
>  
> 
> 
> == Patch ==
> A "patch" is a partial update to only some files in a widget. Consider the 
> use case below.
> 
> Patch Use Case: I have a cookbook extension that contains a bunch of videos, 
> audio, and graphics inside the widget (~500Mb). I've updated the javascript, 
> in only one file (say ~5kb worth of changes) and added/updated localized 
> content. As a developer, I only want to patch the affected file without 
> having to send the whole widget package as an "update". A patch would only 
> add or replace files already contained in the widget package.
> 
> Requirements:
> 1. Must work with the digital signing scheme for widgets. If the update is 
> patching a digitally signed widget, then the patch must contain a new 
> signature over every file in the widget that is equivalent to the widget 
> having been updated.
> 
> Question: Do we need a new mime type for this? (e.g., 
> application/widget-patch).
> 
> Example:
> http://www.w3.org/ns/widgets";
> src = "https://w.example.com/2.1/RC/app.wgt";
> version = "2.1"
>type="patch">
>  Fixed bugs and localized some content
> 
> 
> 
> === End of Life - Kill Switch ===
> The "eol" (end of life) update allows developers to indicate that they are no 
> longer maintaining a widget or provides a means for developers and web site 
> owners to warn users of malicious widgets (or widgets that may have some 
> other issue). In any case, it serves as a kind of "kill switch".
> 
> Use case - end of life: As a developer, I create widget X for user Y that 
> allows them to access temporary service Z. Service Z is only around for 24 
> hours and widget X is useless without service Z. When widget X updates itself 
> after 24 hours, I send an "eof" update informing that user that the widget's 
> usefulness has run out. The user can then uninstall the widget.
> 
> Use case - kill switch: As someone that runs a catalog, I discover that 
> widget X is malware. Because widget X is served from my catalog and gets its 
> updates from my repo, I can mark the next update to be "eol". I also include 
> a description for the author informing them about what issues where found.
> 
> Example:
> http://www.w3.org/ns/widgets";
> version = "2.0"
>type="eol">
>  
>A serious security issue was found in this widget.
>It is highly recommended you uninstall it.
>  
> 
> 
> 
> -- 
> Marcos Caceres
> Opera Software
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [widgets] Removed LocalizableString interface from Widgets API

[Scott Wilson]

On 19 Jan 2011, at 18:39, Marcos Caceres wrote:

> On 1/17/11 1:56 PM, Robin Berjon wrote:
>> On Jan 11, 2011, at 08:24 , Marcos Caceres wrote:
>>> On 1/10/11 4:28 PM, Robin Berjon wrote:
>>> I would argue that it's not particularly complicated to implement,
>>> and we are seeing it used in Opera extensions: we have extensions
>>> in 15 languages as of today in our catalog [0].
>> 
>> Nothing in P+C is super-hard to implement, but the l12n parts account
>> for most of the complexity,
> 
> I've only implemented the i18n stuff in Javascript, but I didn't find it 
> particularly hard (relative to anything else). Opera devs implemented the 
> i18n stuff in a couple of days. The parts that took a long time were the 
> processing model and annoying XML issues not related to the i18n model. I 
> guess complexity is relative, particularly if the implementer sees little 
> return on investment in implementing the feature (then by "complexity" you 
> really mean "I can't be arsed doing it now because I don't *believe* people 
> will use it"... bit of a self-fulfilling prophecy: no one uses the thing that 
> was never implemented).

I'm glad I took the time to implement the i18n code for Apache Wookie. I may 
not see any immediate benefits, but it didn't take a *lot* of work, and if down 
the line it improves our impact further down the line...

>> and the primary reason why such an
>> implementation is more than just reading a Zip archive plus a little
>> extra processing.
> 
> True. But the alternative was no i18n model at all, right? Then we would be 
> in the situation where there would not be any interoperable i18n solution 
> (everyone would roll their own, or an API). Not having a formal i18n solution 
> has several risks and consequences:
> 
>  * The i18n solutions would not be reusable (or simply fragmented).
>  * The i18n solution could be done wrongly [1] (assuming our is correct given 
> the amount of guidance from the i18n WG).
>  * Catalogs would not be able to present localize content (or inform 
> end-users if their language is supported).
>  * User agents could not find the right bits of localized content to display 
> in widget managers.
> 
> Yes, the current solution adds complexity - but the benefits have clearly, in 
> Opera's case, outweighed the costs. For developers, we also greatly 
> simplified the XML P&C i18n solution by not using ITS and simply relying on 
> what XML already provided. WRT folder-based localization, it closely matches 
> the i18n models used in software development (and was part of most widget 
> platforms when we did the original landscape analysis for widgets; we were 
> just following what was best practice at the time). So, it's not like we 
> introduced anything weird.

The folder localization stuff we implemented in one filter class.

> 
>>> TOTAL (all languages): 335 of which 74 use another language (20% of
>>> the catalog). 20% is fairly significant and certainly indicative of
>>> "actual usage". To put into perspective, we have had over 4 million
>>> downloads of extensions since launch.
>> 
>> If it's only 20% then I maintain that it's not enough to justify the
>> feature. We have a 20/80 situation here, when we'd want an 80/20 :)
> 
> It's not realistic to expect every developer to cover 80% of languages - so I 
> don't understand your argument. A significant number of Europeans know on 
> average 2 languages and some content simply does not make sense to be 
> localized. From [0]:
> 
> "56% of citizens in the EU Member States are able to hold a conversation in 
> one language apart from their mother tongue... Notwithstanding, a minority 
> speaking either an official EU language other than the state language or a 
> non-European language as their mother tongue is recorded in every country 
> polled."
> 
> The fact that developers are making an effort to cover 20% of languages 
> cannot be understated or cast off by the arbitrary 80/20 rule. From [0]:
> 
> "With respect to the goal for every EU citizen to have knowledge of two 
> languages in addition to their mother tongue, 28% of the respondents state 
> that they speak two foreign languages well enough to have a conversation. 
> This is especially the case in Luxembourg (92%), the Netherlands (75%) and 
> Slovenia (71%). 11% of the respondents indicate that they master at least 
> three languages apart from their mother tongue."
> 
> Having the 20% of developers shows that, in fact, developers *do* care about 
> localizing content and they do understand that they are delivering their 
> content to a multilingual environment (if it was 28%, then we would be at the 
> EU average). Opera has done virtually no promotion of the i18n model 
> (developers just picked it up and ran with it), and I firmly believe once we 
> educate developers on how easy the model is to use, we will see even higher 
> numbers of developers making use of it.

I'm working on an EU education project at the moment, where we'll be using 

Re: [widgets] Storage keys and ECMAScript incompatibility?

[Scott Wilson]

On 15 Dec 2010, at 15:50, Tab Atkins Jr. wrote:

> On Wed, Dec 15, 2010 at 5:29 AM, Scott Wilson
>  wrote:
>> We've come across an issue with storage keys in Widget preferences; namely
>> that the Web Storage spec [1] states that:
>> Keys are strings. Any string (including the empty string) is a valid key.
>> Values can be any data type supported by the structured clone algorithm.
>> However, common guidance on JavaScript states that:
>> Variable names must begin with a letter or the underscore character
>> ECMAScript[3] follows the Unicode identifier syntax[4], which defines
>> variable names as starting with:
>> Characters having the Unicode General_Category of uppercase letters (Lu),
>> lowercase letters (Ll), titlecase letters (Lt), modifier letters (Lm), other
>> letters (Lo), letter numbers (Nl), minus Pattern_Syntax
>> and Pattern_White_Space code points, plus stability extensions
>> So we get into problems using keys that begin with digits, which are allowed
>> as far as I can tell in WebStorage and Widgets, but not in ECMAScript, and
>> things like "widgets.preferences.12345="xyz" throw exceptions.
> 
> timeless got it.  Only a subset of possible keys can be used in the
> dot syntax.  Everything else can be used in the array notation
> instead.  This is perfectly fine.
> 
> ~TJ

OK, we'll implement using array notation instead. 

Thanks!

smime.p7s
Description: S/MIME cryptographic signature

[widgets] Storage keys and ECMAScript incompatibility?

[Scott Wilson]

We've come across an issue with storage keys in Widget preferences; namely that 
the Web Storage spec [1] states that:

Keys are strings. Any string (including the empty string) is a valid key. 
Values can be any data type supported by the structured clone algorithm. 

However, common guidance on JavaScript states that:

Variable names must begin with a letter or the underscore character

ECMAScript[3] follows the Unicode identifier syntax[4], which defines variable 
names as starting with:

Characters having the Unicode General_Category of uppercase letters (Lu), 
lowercase letters (Ll), titlecase letters (Lt), modifier letters (Lm), other 
letters (Lo), letter numbers (Nl), minus Pattern_Syntax and Pattern_White_Space 
code points, plus stability extensions

So we get into problems using keys that begin with digits, which are allowed as 
far as I can tell in WebStorage and Widgets, but not in ECMAScript, and things 
like "widgets.preferences.12345="xyz" throw exceptions.

[1] http://www.w3.org/TR/webstorage/
[2] http://www.w3schools.com/js/js_variables.asp
[3] http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf
[4] http://unicode.org/reports/tr31/

smime.p7s
Description: S/MIME cryptographic signature

[widgets] Some possible i18n test bugs

[Scott Wilson]

I've identified a few more possible test bugs. If there are no objections I'll 
make the changes I've suggested below and commit them.

1. i18nrl20.wgt Tests that nested LRO and RTL directions apply correctly to the 
name element. To pass, the displayed value of the name element must render as 
"< PASSED -->".

http://www.w3.org/ns/widgets";>
   < PAS<-- SED


However I'm pretty sure that the result you should get from this is:

< PASDES-->

Which is what Wookie generates. I think the test should be:

http://www.w3.org/ns/widgets";>
   < PAS<-- DES


2. 18nrlo02.wgt Tests that RLO direction applies to the name element's short 
attribute. To pass, the displayed value must render as "PASSED".

http://www.w3.org/ns/widgets";>
a TSET (3)


This clearly isn't correct. I think it should be:

http://www.w3.org/ns/widgets";>
   PDESSA (3)



3.i18nrtl21.wgt Tests that nested RTL and LRO directions apply correctly to the 
name element. To pass, the displayed value must render as "< PASSED -->".
http://www.w3.org/ns/widgets";>
   PASSED --> >
   The name should be "< PASSED -->"


I get "< SED-->SAP" for this one; I think this should be:

http://www.w3.org/ns/widgets";>
   SAP >SED -->
   The name should be "< PASSED -->"


4. 18nrtl22.wgt Tests that nested RTL and RLO directions apply correctly to the 
name element. To pass, the displayed value must render as "< PASSED -->".

http://www.w3.org/ns/widgets";>
   PAS<-- DES >
   The name should be "< PASSED -->"


I get "< SED-->SAP" for this one; I think this should be:

http://www.w3.org/ns/widgets";>
   SAP ><-- DES
   The name should be "< PASSED -->"



S

smime.p7s
Description: S/MIME cryptographic signature

Re: [widgets] Error in i18n tests for features

[Scott Wilson]

On 3 Dec 2010, at 16:54, Marcos Caceres wrote:

> On 12/3/10 5:38 PM, Scott Wilson wrote:
>> 
>> On 3 Dec 2010, at 16:28, Marcos Caceres wrote:
>> 
>>> On Fri, Dec 3, 2010 at 12:05 PM, Scott Wilson
>>>   wrote:
>>>> # i18nlro30 (download, files)
>>>> 
>>>> Tests that LRO direction does not apply to the feature element's required
>>>> attribute. To pass, the value of the required attribute must be treated as
>>>> "false".
>>>> 
>>>> The actual feature is:
>>>> 
>>>> So as the feature is unsupported by the UA, the feature is ignored and the
>>>> value of the required attribute is irrelevant. (All other xxx30 tests have
>>>> the same issue).
>>> 
>>> Can you suggest an alternative way to test this?
>> 
>> How about:
>> 
>> 
>> 
>> ?
> 
> That might be ok, but the problem is still that if false is treated as 
> "eslaf" it would still default to "true" (which is why I wrote the test with 
> the bogus feature):
> 
> "If a required attribute is used, then let required-feature be the result of 
> applying the rule for getting a single attribute value to the required 
> attribute. If the required attribute is not used or if required-feature is 
> not a valid boolean value, then let the value of required-feature be the 
> value 'true'."
> 

Ah OK I think I understand now, so the actual test is OK if the UA doesn't 
throw an exception and has an empty feature list (its not supported, and 
required is false). You shouldn't see a "false" value on the Feature as if all 
goes well, it won't be used?



smime.p7s
Description: S/MIME cryptographic signature

Re: [widgets] Error in i18n tests for features

[Scott Wilson]

On 3 Dec 2010, at 16:28, Marcos Caceres wrote:

> On Fri, Dec 3, 2010 at 12:05 PM, Scott Wilson
>  wrote:
>> # i18nlro30 (download, files)
>> 
>> Tests that LRO direction does not apply to the feature element's required
>> attribute. To pass, the value of the required attribute must be treated as
>> "false".
>> 
>> The actual feature is:
>> 
>> So as the feature is unsupported by the UA, the feature is ignored and the
>> value of the required attribute is irrelevant. (All other xxx30 tests have
>> the same issue).
> 
> Can you suggest an alternative way to test this?

How about:



?

> 
> -- 
> Marcos Caceres
> Opera Software ASA, http://www.opera.com/
> http://datadriven.com.au



smime.p7s
Description: S/MIME cryptographic signature

[widgets] Test widget has wrong content

[Scott Wilson]

See:

http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-lro/001/i18nlro01.wgt

This is pretty obviously not what should be in here!

S

smime.p7s
Description: S/MIME cryptographic signature

[widgets] Error in i18n tests for features

[Scott Wilson]

# i18nlro30 (download, files)
Tests that LRO direction does not apply to the feature element's required 
attribute. To pass, the value of the required attribute must be treated as 
"false".


The actual feature is:



So as the feature is unsupported by the UA, the feature is ignored and the 
value of the required attribute is irrelevant. (All other xxx30 tests have the 
same issue).

smime.p7s
Description: S/MIME cryptographic signature

[widgets] WARP test bugs

[Scott Wilson]

# hg (download, files)
Tests that the UA processes an access element with a valid origin. To pass, the 
access list must contain a single entry where the scheme is "http", the host is 
"w3.org", the port is "80", and subdomains is "false".

The origin contains a trailing slash, which is treated as path information and 
hence the origin is treated as being invalid:

  http://w3.org/"/>

# la (download, files)
Tests that the UA processes access elements using the ToASCII algorithm. To 
pass, the access list must contain one entry where the scheme is "http", the 
host is "xn--xkry9kk1bz66a.cn", the port is "80", and subdomains is "true".


 Unless I'm missing something here there are actually two valid access elements 
in the widget, not one:

  http://हिन्दी.idn.icann.org"/>
  http://उदाहरण.परीक्षा"; subdomains="true"/>
# ma (download, files)
Tests that the UA processes multiple access elements. To pass, the access list 
must contain two entries; one where the scheme is "http", the host is "w3.org", 
the port is "80", and subdomains is "true", one where the scheme is "http", the 
host is "pass", the port is null, and subdomains is "false". The order of the 
entries is not important.


The second element contains "ietf.org" not "pass".

smime.p7s
Description: S/MIME cryptographic signature

[widgets] test "viewh" in error

[Scott Wilson]

# viewh (download, files)
Test the UA's ability process a viewmodes attribute containing supported and 
unsupported values. To pass, the viewmodes list should be "windowed maximized" 
if the UA supports all of these.


The widget itself contains viewmodes="windowed not-supported floating" - so a 
correct answer would be "windowed floating".




smime.p7s
Description: S/MIME cryptographic signature

[widgets] test "bn" in error

[Scott Wilson]

# bn (download, files)
Tests the UA's ability to deal with custom icon declarations in the config 
document and matching default icons. To pass, the icons list must contain a 
pointer to "icons/pass.png", and "locales/en/icon.jpg" (ordering of the items 
in the list is irrelevant).


The actual icons included are "icons/pass.png" and "locales/en/icon.png" (not 
.jpg).

smime.p7s
Description: S/MIME cryptographic signature

[widgets] Error in test case "bm"

[Scott Wilson]

# bm (download, files)
Tests the UA's ability to deal with custom icon declaration in the config 
document and matching default icons. To pass, the icons list must contain a 
pointer to "locales/en/icon.jpg", and "icon.png", which is at the root of the 
widget. The icons list can be in any order, so long as it contains "icon.png" 
and "locales/en/icon.jpg".


The download contains two icons, but one of these is called "333icon.png" and 
so would be ignored.

smime.p7s
Description: S/MIME cryptographic signature

[widgets] missing tests?

[Scott Wilson]

Tests bd,be,bf for assertion ta-DwhJBIJRQN seem to have gone - have these been 
removed from the test suite or been renamed?

smime.p7s
Description: S/MIME cryptographic signature

[widgets] test "dl" is in error

[Scott Wilson]

# dl (download, files) Expected: invalid
Test the ability of the UA to verify a zip archive. To pass, the user agent 
must treat this as an invalid widget (archive is encrypted - password is test).

The download is just a regular zip archive and isn't encrypted.

smime.p7s
Description: S/MIME cryptographic signature

[Embedding] running widgets in a regular web page ???

[Scott Wilson]

(NB changed subject prefix to "[Embedding]" as per Art's suggestion)

On 26 Nov 2010, at 18:37, Peter Dekkers wrote:

> First of all, thanks to everyone replying and providing useful background to 
> this first time poster. I did go through the provided links of the past 
> threads and the different kind of proposed approaches. I think however I 
> might have not made myself completely clear (or of course I misunderstood 
> some of the replies :). 
> 
> I think it would be great if the SAME code base could run "standalone" and in 
> a web page (that is with the help of a "serverside container" like Wookie or 
> JBaron). Injected scripts can help with some issues, I also use this on the 
> JBaron demo. But certainly this is not going to solve all issues.
> 
> For example to be truly compatible in both environment this would mean that 
> widget code should invoke widget.getProxyUrl/proxify before calling an 
> XMLHttpRequest, because the code base doesn't know on which environment it 
> will be run. And the consequence would be of course that this method would 
> need to be part of the specification.

I think the main question is where we have to solve this. When I raised this 
previously, there was a general feeling that the cross-origin XHR cases ought 
to be handled by CORS and XHR2 not by Widgets, which I think is sensible when 
looking at the longer-term spec roadmap. 

However, we do have an issue of making things work until browsers implement 
these.

The route we've taken is server-side proxies and to make use of WARP to 
automatically add policies to the proxy whitelist. We then need a means to 
proxify requests. 

One approach is an explicit proxify() method. Other possibilities may be to 
provide a special XHR object such as a modified JQuery. None of these is 100% 
satisfactory - as you point out, you get the issue of proxify() being 
non-standard and so widgets need tweaking for other environments.

I think the next thing we might explore is using WARP as a way to identify URL 
patterns that are dynamically rewritten by the container. So if WARP contains 
"twetter.com" then we rewrite any URLs in the Widget's JS code containing 
"twetter.com" with a proxy URL.

Again, not 100% guaranteed either. But maybe better than proxify() as the 
Widget code will be the same for web and non-web containers, we may just have 
to tweak them a little for web containers in some cases.

> And my interest/question was, is this planned/foreseen? Will it be possible 
> at the end to run the same "specification compliant widget" both "standalone" 
> as also part of a web page (again with using something like using Wookie or 
> JBaron)??? In the second scenario of course it won't necessary be the 
> end-user who installed the application.It would be more likely the site owner 
> who included the application on one of his pages.

I think it certainly should be - this is how a lot of our commercial partners 
want to use them, for example: have a single Widget developed and tested that 
can be run in their portal/intranet/extranet via Wookie AND be downloaded to 
run on a smartphone.

> (I guess an alternative would be to make these additional methods part of a 
> feature and mention this in the config.xml. But then regular widgets won't 
> run within web pages.)

In some ways this is more in the spirit of the spec than what we are doing now, 
but it also does defeat the purpose of "one widget any platform" as you say. 

> And again, thanks for all the feedback and ideas so far. 
> 
> 
> regards,
> 
> Peter
>  
> 
> On Fri, Nov 26, 2010 at 6:19 PM, Marcos Caceres  wrote:
> On Fri, Nov 26, 2010 at 1:10 PM, Nathan  wrote:
> > Peter Dekkers wrote:
> >>
> >> I've been developing a platform for running multiple types of widgets in
> >> regular web pages and of course support for the W3C widgets should not be
> >> missing. A very nice specification. I especially like the fact that the
> >> "deployment unit" contains all the files and the spec itself tries to be
> >> as
> >> clear and precise as possible.
> >>
> >> However the specification seems to be geared towards "standalone desktop
> >> applications", and not so much running the widgets as part of a regular
> >> web
> >> page. When I investigated a little more, there doesn't seem however too
> >> much
> >> stopping the widget running in an ordinary web page. Two of the main
> >> functions missing that I could identify so far are:
> >>
> >> - A widget.onReady() function that gives the page the change to prepare
> >> everything before the widget dependent code is executed.
> >> - Some way to proxy XMLHttpRequest in order to avoid not same origin
> >> security validations. A simple way would be a widget function that simply
> >> rewrites the URL to a proxied URL.
> >>
> >> Personally I think it would be great to have the W3C widgets run both
> >> inside
> >> a normal webpage and as a standalone application. However is this also
> >> something that might be considered by the p

Re: [Widgets] running widgets in a regular web page ???

[Scott Wilson]

On 26 Nov 2010, at 07:34, Peter Dekkers wrote:

> I've been developing a platform for running multiple types of widgets in 
> regular web pages and of course support for the W3C widgets should not be 
> missing. A very nice specification. I especially like the fact that the 
> "deployment unit" contains all the files and the spec itself tries to be as 
> clear and precise as possible. 
> 
> However the specification seems to be geared towards "standalone desktop 
> applications", and not so much running the widgets as part of a regular web 
> page. When I investigated a little more, there doesn't seem however too much 
> stopping the widget running in an ordinary web page.

I think the original landscape report mostly focussed on desktop-based widget 
engines, but the spec itself is geared these days to be a general 
packaged-web-app format for use in browsers, mobile devices, desktops, TVs and 
appliance, and all kinds of other uses. 

> Two of the main functions missing that I could identify so far are:
> 
> - A widget.onReady() function that gives the page the change to prepare 
> everything before the widget dependent code is executed.

Hmm, not sure about this one?

> - Some way to proxy XMLHttpRequest in order to avoid not same origin security 
> validations. A simple way would be a widget function that simply rewrites the 
> URL to a proxied URL.

We do this in Apache Wookie:

http://incubator.apache.org/wookie/faq.html

> Personally I think it would be great to have the W3C widgets run both inside 
> a normal webpage and as a standalone application. However is this also 
> something that might be considered by the people in charge of the 
> specifications, or is this something that will never be in scope? Any 
> enlightenment would be great.

Again, see Apache Wookie:

http://incubator.apache.org/wookie/

There are also a few other browser-based W3C Widgets implementations out there 
I've come across.

> P.S For those interested, on http://www.jbaron.com:9090/w3c there are some 
> Opera widgets running in a web page as a small proof of concept (certainly 
> not a complete implementation). The same site also has some pages with other 
> types of widgets. 

Cool, its got one of mine! :-D

> 
> 
> regards,
> 
> Peter



smime.p7s
Description: S/MIME cryptographic signature

Re: [Widgets] and OAuth or other similar redirect-based protocols

[Scott Wilson]

Hi Bryan,

We've looked at this in Apache Wookie, which does use Widgets in a 
browser/webserver context. The general approach we've been discussing is 
similar to how Apache Shindig handles oAuth - to put the oAuth logic within the 
framework itself rather than in the Widget. So these issues around redirect and 
origin aren't a problem for the Widget but are instead part of how the Widget 
UA (aka Widget Runtime or WRT) implements oAuth. So oAuth would be a "feature" 
injected at runtime by the UA/WRT, and the Widget would have to access it via a 
JS API. These JS calls are then handled by the UA/WRT which has to handle the 
other "leg" of the oAuth call and render the authz screens presented for the 
user.

That said there are some issues around managing consumer secrets that are 
common to frameworks that we still have to address - as Widgets are portable 
and transparent you can't just encode the consumer secret in the widget's 
config.xml and distribute it on the web. Which means the framework has to 
manage them and request them for each Widget. Also, we don't have a standard 
for the JS API used for an oAuth feature; one option is to try to follow the 
same conventions as in OpenSocial[1] .

(If you're interested, there is a discussion on this topic on the wookie-dev 
list [2])

S 

[1] 
http://opensocial-resources.googlecode.com/svn/spec/1.1/Core-Gadget.xml#gadgets.oauth.Popup
[2]  http://www.mail-archive.com/wookie-...@incubator.apache.org/msg01922.html

On 1 Nov 2010, at 12:19, Bryan Sullivan wrote:

> Hi,
> Can anyone point to an example of how to use HTTP redirect-based protocols 
> such as OAuth with widgets? There seem to be issues with the use of these 
> protocols due to the difference between widgets and browser-based webapps, in 
> particular with the two aspects:
> widgets cannot access network resources unless an access request/dependency 
> to the domain is declared per the WARP spec. Thus any domain that is to be 
> used in a redirect-based protocol needs to be known up-front and explicitly 
> included per WARP.
> for widgets, there is no “origin” or at least “base” that can be used in a 
> redirect-based protocol. All that widgets could expose for redirect purposes 
> are relative URIs for their resources. Thus redirect protocols/designs in 
> which one widget page makes a request which is intended to result in a 
> redirect to another widget page, will not work.
> 
> An example of how to do this for widgets, e.g. a Twitter-enabled widget (as 
> Twitter uses OAuth) would be very helpful.
> 
> It does seem that applications using XHR for this (as compared to web 
> links/anchors etc) would/should be in total control of the operation of XHR, 
> but they would need to handle all HTTP requests and responses (including 
> redirects).
> 
> Apologies in advance if this request is not clear from a technical 
> perspective. 
> 
> Bryan



smime.p7s
Description: S/MIME cryptographic signature

Re: [Widgets] Mozilla open apps

[Scott Wilson]

On 20 Oct 2010, at 19:40, Mike Hanson wrote:

> Hi there -
> 
> I can speak for the technical aspects of the Apps project and relay feedback 
> as needed.
> 
> We had looked at the Widget Packaging spec earlier in the project and had 
> steered away from it because we were focused on the "in-browser/live URL" use 
> case.  But as we added icons, names, descriptions, and whatnot, we've 
> converged back on something close to Widget Packaging.
> 
> So... I think, as you note, it's worth making the effort -- I propose that we 
> try to figure out how to make the Widget spec fit our current use case, and, 
> if it doesn't, see if we can find a small number of deltas that get us there.

Great! 

> I'll try to summarize the differences here:
> 
> In-Browser/"live content" usage
> Our goal is to encompass "in-browser" application usage, where some subset of 
> normal web browsing activity is identified as an "app".  
> 
> This means that we need to identify some subset of the URL value space that 
> "belongs" to an app.  Our current approach (which is close to the one 
> proposed by Google [1]) is to identify a URL set (Google allows regexes; we 
> propose domain-matching with a path prefix).  Google proposes allowing a 
> carve-out of "browsable URLs", which can be visited without leaving the app, 
> presumably for federated login.
> 
> Specifically, this means that the content element would need to be replaced 
> or augmented with some sort of app_urls or somesuch.  It also seems like the 
> HTML5 App Cache proposal is addressing the same problem space as content; is 
> there some way to harmonize all of this?  If we get this right we can perhaps 
> get a smooth continuum from "live web site" to "dedicated brower instance" to 
> "widget".
> 
> We also intend to experiment with embedding URLs for service endpoints -- for 
> example, a cross-document postMessage sink.  I don't see an element that we 
> could adopt for that purpose yet; perhaps we could propose an extension.

In Apache Wookie we have several proposals for inter-widget communications 
(IWC). A good summary of existing approaches has been developed by Ivan Zuzak 
[1] and we are taking these forward through community contributions. In general 
we have found IWC to be sufficiently orthogonal to the core Widget packaging 
and APIs to be implemented using the existing Feature extension mechanism 
rather than needing anything special in the spec.

> Per-application metadata repository and access API
> We propose that the "application repository" maintain some metadata that is 
> in addition to, and along side, the manifest.  Specifically, an authorization 
> URL, signature, installation location and date, and perhaps an update URL.

Update URLs are described in Widget Updates [2] - worth taking a look at.

Signatures are described in Widgets: Digital Signatures [3] - also worth a look.

I agree that "app store metadata" is also a useful thing to look at. Some time 
ago there was a discussion on this list of proposing some additions to the Atom 
Syndication Format for sharing app store listings, and it may be useful to 
revisit that.

> The gist of our approach (and the part that is really new, I think) is that 
> JavaScript running in some web context can ask, "has the user installed an 
> app for my domain?"   And then, further, "if the user has an authorization 
> URL for my domain, load it now".
> 
> You could try to use the Widget API for this, but the trust model isn't 
> exactly right.  Our intent is that the user has a trust relationship with a 
> store or directory, and has a less trusted relationship with the app; the app 
> does not discover the authorization URL, for example.  In our thinking this 
> implies that there is a "app repository" object that has a couple methods; 
> AFAIK there isn't an equivalent object that has the "list of all installed 
> widgets" in the spec.  Am I missing something?

Apache Wookie also uses Widgets in the in-browser case. We just add our own 
parameters to the URL to identify the Widget Instance as opposed to the 
"canonical" widget URI.

In our case, the specific Wookie install (the "app store", whether generally 
open or enterprise-specific) is assumed to be trusted by the container (e.g. 
Wordpress, JetSpeed etc).  It is also responsible for providing the list of 
installed widgets to the container via a REST API [4] - is that the same sort 
of thing?

> XML vs. JSON
> Cultural nit: many web developers have trouble with complex XML encodings.  
> It's frustrating, but true.  Would the specification of a JSON dialect be 
> amenable, or is it that a non-starter?

I can't see that being much of an issue. Though TBH the processing of the 
semantics of the package is more challenging than the syntax.

> Localization Model
> The xml:lang based approach is structural analogous (though somewhat tedious 
> to handle in JSON, but that's not really important).  In the absence of a 
> content element, the folder-based

[Widgets] Mozilla open apps

[Scott Wilson]

I've just had a look at this:

https://apps.mozillalabs.com/

In some respects this is very much what we are aiming for (apps using 
HTML+JS+CSS) however it proposes a new proprietary "app manifest" format for 
Widgets that is almost identical to P&C, plus an auto-update spec (that isn't 
Widget Updates). So a lot of reinventing the wheel.

Does anyone here have any contact with the project?

S

smime.p7s
Description: S/MIME cryptographic signature

Re: Comment on Widget Interface...

[Scott Wilson]

On 5 Oct 2010, at 01:28, Charles McCathieNevile wrote:

> On Mon, 04 Oct 2010 23:32:46 +0200, Scott Wilson 
>  wrote:
> 
>> Actually, just to totally contradict myself, we implemented the locale 
>> attribute of the Widget interface and forget to take it out again when it 
>> was removed from the spec :-)
> 
> The functionality Addison wants would most logically be defined in The Widget 
> Interface, no?

It used to be:

http://www.w3.org/TR/2009/WD-widgets-apis-20090423/

It was removed in later revisions.

> 
> cheers
> 
>> On 30 Sep 2010, at 20:37, Scott Wilson wrote:
>> 
>>> On 30 Sep 2010, at 16:51, Phillips, Addison wrote:
>>> 
>>>> Hi Art,
>>>> 
>>>> No, I don't think it does. While the means by which the (user/system 
>>>> default) locale is determined may be implementation dependent, it is still 
>>>> necessary that the runtime determine what it is. The Widget interface thus 
>>>> needs to provide access to what it is. Otherwise how can the script 
>>>> calling the interface determine what language it is getting for the name, 
>>>> shortname, etc.? Or what locale the widget is actually using in its 
>>>> runtime? Obtaining this would be useful if the script were to request 
>>>> content or data formatting remotely (or do so locally using the JavaScript 
>>>> I18N extension that is being developed).
>>> 
>>> At present in Wookie we generate a widget instance using localization 
>>> parameters passed to our API, so the information you get from the widget 
>>> interface will be localized. However for things like making AJAX calls to 
>>> other services, you are correct that this information will not be available 
>>> in the Widget runtime - seems like a reasonable UC.
>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> Addison
>>>> 
>>>> Addison Phillips
>>>> Globalization Architect (Lab126)
>>>> Chair (W3C I18N, IETF IRI WGs)
>>>> 
>>>> Internationalization is not a feature.
>>>> It is an architecture.
>>>> 
>>>> 
>>>>> -Original Message-
>>>>> From: Arthur Barstow [mailto:art.bars...@nokia.com]
>>>>> Sent: Thursday, September 30, 2010 6:18 AM
>>>>> To: Phillips, Addison
>>>>> Cc: public-webapps
>>>>> Subject: Re: Comment on Widget Interface...
>>>>> 
>>>>> 
>>>>> Hi Addison,
>>>>> 
>>>>> On 9/7/10 6:06 PM, ext Phillips, Addison wrote:
>>>>>> Hello Webapps WG,
>>>>>> 
>>>>>> (This is a personal comment and is not necessarily indicative of
>>>>> the I18N WG's opinion)
>>>>>> 
>>>>>> In Section 5 (The Widget Interface), the interface provides for
>>>>> retrieving values such as 'name', 'shortName', etc. In Widgets P&C,
>>>>> these can be localized in the configuration document (I assume that
>>>>> the configuration document in this document means the same document
>>>>> as P&C??). There is no mention of whether or how this value is
>>>>> localized or if the locale/language is subject to programmatic
>>>>> control (I assume not, since it is not mentioned).
>>>>>> 
>>>>>> Could there be an explicit mention of the language/locale and how
>>>>> it interacts with user-agent? Can/should there be an accessor for
>>>>> language? How about a way of querying the value by locale?
>>>>> Support for locale was part of the Widget Interface spec but as we
>>>>> worked through the localization model for the Packaging and
>>>>> Configuration spec, we decided to remove it (at least for this
>>>>> version
>>>>> of the spec). The Packaging spec includes the gist of the
>>>>> rationalization for this decision:
>>>>> 
>>>>> [[
>>>>> http://www.w3.org/TR/widgets/#step-5--derive-the-user-agents-locale
>>>>> 
>>>>> As there are numerous ways a user agent can derive the end-user's
>>>>> preferred languages and regional settings, the means by which those
>>>>> values are derived are beyond the scope of this specification and
>>>>> left
>>>>> up to the implementation.
>>>>> ]]
>>>>> 
>>>>> I suppose one could argue the Widget Interface implies the above
>>>>> indirectly (via the reference to P&C spec). However, I don't see
>>>>> any
>>>>> harm if the above text were copied into the Interface spec. Would
>>>>> doing
>>>>> so address your concern?
>>>>> 
>>>>> -Art Barstow
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> Charles McCathieNevile  Opera Software, Standards Group
>je parle français -- hablo español -- jeg lærer norsk
> http://my.opera.com/chaals   Try Opera: http://www.opera.com

Re: Comment on Widget Interface...

[Scott Wilson]

Actually, just to totally contradict myself, we implemented the locale 
attribute of the Widget interface and forget to take it out again when it was 
removed from the spec :-)

On 30 Sep 2010, at 20:37, Scott Wilson wrote:

> On 30 Sep 2010, at 16:51, Phillips, Addison wrote:
> 
>> Hi Art,
>> 
>> No, I don't think it does. While the means by which the (user/system 
>> default) locale is determined may be implementation dependent, it is still 
>> necessary that the runtime determine what it is. The Widget interface thus 
>> needs to provide access to what it is. Otherwise how can the script calling 
>> the interface determine what language it is getting for the name, shortname, 
>> etc.? Or what locale the widget is actually using in its runtime? Obtaining 
>> this would be useful if the script were to request content or data 
>> formatting remotely (or do so locally using the JavaScript I18N extension 
>> that is being developed).
> 
> At present in Wookie we generate a widget instance using localization 
> parameters passed to our API, so the information you get from the widget 
> interface will be localized. However for things like making AJAX calls to 
> other services, you are correct that this information will not be available 
> in the Widget runtime - seems like a reasonable UC.
> 
>> 
>> Thanks,
>> 
>> Addison
>> 
>> Addison Phillips
>> Globalization Architect (Lab126)
>> Chair (W3C I18N, IETF IRI WGs)
>> 
>> Internationalization is not a feature.
>> It is an architecture.
>> 
>> 
>>> -Original Message-
>>> From: Arthur Barstow [mailto:art.bars...@nokia.com]
>>> Sent: Thursday, September 30, 2010 6:18 AM
>>> To: Phillips, Addison
>>> Cc: public-webapps
>>> Subject: Re: Comment on Widget Interface...
>>> 
>>> 
>>> Hi Addison,
>>> 
>>> On 9/7/10 6:06 PM, ext Phillips, Addison wrote:
>>>> Hello Webapps WG,
>>>> 
>>>> (This is a personal comment and is not necessarily indicative of
>>> the I18N WG's opinion)
>>>> 
>>>> In Section 5 (The Widget Interface), the interface provides for
>>> retrieving values such as 'name', 'shortName', etc. In Widgets P&C,
>>> these can be localized in the configuration document (I assume that
>>> the configuration document in this document means the same document
>>> as P&C??). There is no mention of whether or how this value is
>>> localized or if the locale/language is subject to programmatic
>>> control (I assume not, since it is not mentioned).
>>>> 
>>>> Could there be an explicit mention of the language/locale and how
>>> it interacts with user-agent? Can/should there be an accessor for
>>> language? How about a way of querying the value by locale?
>>> Support for locale was part of the Widget Interface spec but as we
>>> worked through the localization model for the Packaging and
>>> Configuration spec, we decided to remove it (at least for this
>>> version
>>> of the spec). The Packaging spec includes the gist of the
>>> rationalization for this decision:
>>> 
>>> [[
>>> http://www.w3.org/TR/widgets/#step-5--derive-the-user-agents-locale
>>> 
>>> As there are numerous ways a user agent can derive the end-user's
>>> preferred languages and regional settings, the means by which those
>>> values are derived are beyond the scope of this specification and
>>> left
>>> up to the implementation.
>>> ]]
>>> 
>>> I suppose one could argue the Widget Interface implies the above
>>> indirectly (via the reference to P&C spec). However, I don't see
>>> any
>>> harm if the above text were copied into the Interface spec. Would
>>> doing
>>> so address your concern?
>>> 
>>> -Art Barstow
>>> 
>>> 
>> 
>> 
> 

Re: Comment on Widget Interface...

[Scott Wilson]

On 30 Sep 2010, at 16:51, Phillips, Addison wrote:

> Hi Art,
> 
> No, I don't think it does. While the means by which the (user/system default) 
> locale is determined may be implementation dependent, it is still necessary 
> that the runtime determine what it is. The Widget interface thus needs to 
> provide access to what it is. Otherwise how can the script calling the 
> interface determine what language it is getting for the name, shortname, 
> etc.? Or what locale the widget is actually using in its runtime? Obtaining 
> this would be useful if the script were to request content or data formatting 
> remotely (or do so locally using the JavaScript I18N extension that is being 
> developed).

At present in Wookie we generate a widget instance using localization 
parameters passed to our API, so the information you get from the widget 
interface will be localized. However for things like making AJAX calls to other 
services, you are correct that this information will not be available in the 
Widget runtime - seems like a reasonable UC.

> 
> Thanks,
> 
> Addison
> 
> Addison Phillips
> Globalization Architect (Lab126)
> Chair (W3C I18N, IETF IRI WGs)
> 
> Internationalization is not a feature.
> It is an architecture.
> 
> 
>> -Original Message-
>> From: Arthur Barstow [mailto:art.bars...@nokia.com]
>> Sent: Thursday, September 30, 2010 6:18 AM
>> To: Phillips, Addison
>> Cc: public-webapps
>> Subject: Re: Comment on Widget Interface...
>> 
>> 
>>  Hi Addison,
>> 
>> On 9/7/10 6:06 PM, ext Phillips, Addison wrote:
>>> Hello Webapps WG,
>>> 
>>> (This is a personal comment and is not necessarily indicative of
>> the I18N WG's opinion)
>>> 
>>> In Section 5 (The Widget Interface), the interface provides for
>> retrieving values such as 'name', 'shortName', etc. In Widgets P&C,
>> these can be localized in the configuration document (I assume that
>> the configuration document in this document means the same document
>> as P&C??). There is no mention of whether or how this value is
>> localized or if the locale/language is subject to programmatic
>> control (I assume not, since it is not mentioned).
>>> 
>>> Could there be an explicit mention of the language/locale and how
>> it interacts with user-agent? Can/should there be an accessor for
>> language? How about a way of querying the value by locale?
>> Support for locale was part of the Widget Interface spec but as we
>> worked through the localization model for the Packaging and
>> Configuration spec, we decided to remove it (at least for this
>> version
>> of the spec). The Packaging spec includes the gist of the
>> rationalization for this decision:
>> 
>> [[
>> http://www.w3.org/TR/widgets/#step-5--derive-the-user-agents-locale
>> 
>> As there are numerous ways a user agent can derive the end-user's
>> preferred languages and regional settings, the means by which those
>> values are derived are beyond the scope of this specification and
>> left
>> up to the implementation.
>> ]]
>> 
>> I suppose one could argue the Widget Interface implies the above
>> indirectly (via the reference to P&C spec). However, I don't see
>> any
>> harm if the above text were copied into the Interface spec. Would
>> doing
>> so address your concern?
>> 
>> -Art Barstow
>> 
>> 
> 
> 

[widgets] progress on i18n tests

[Scott Wilson]

I've been having a go at implementing the various i18n test cases in Apache 
Wookie. I'm planning on processing them in two ways:

1. For the parser, checking the correct values are being persisted for text 
direction, both for the element's dir attributes where allowed, and also that 
 tags are preserved in content where allowed.
2. For the server, checking the information is rendered OK in the admin 
interface.

Its a bit of an unusual case as Wookie doesn't tend to render the widget 
metadata directly to users itself, but instead provides it to the container via 
an API where it can be rendered (e.g. in widget galleries), hence I'll be 
testing how the admin interface renders it - the metadata itself should be OK 
as long as the parser is extracting the metadata correctly.

Anyway, its progressing OK on the parser front, just a couple of minor test 
issues so far, e.g. tests i18n-023 uses "test.png" instead of "pass.png". I've 
put automated testing in for around 60% of the test cases now.

I don't know how long it will take to develop some unit tests to cover the 
server, I'll take a look at that next week sometime.

S

Re: Widgets - WARP, Widgets Updates and Digital Signatures

[Scott Wilson]

On 17 Sep 2010, at 01:30, Marcos Caceres wrote:

> Hi Nathan,
> 
>> There are many applications that are currently stuck using a server
>> because there is no clear path to deploying 100% client side
>> applications, examples include micro-blogging clients, note/task-pads,
>> image editors, contact managers, cms/blogging software (think admin),
>> well, any application which doesn't natively need a server and where
>> client side persistence/caching more than suits, or where the
>> data/api(s) being used within the application are exposed via HTTP (that
>> covers almost every "web app" I can think of).
> 
> Some applications are happy to live on the server. Others can be written as 
> native apps. And then some can be written as W3C widgets, sure (also, have 
> you tried Opera Unite? it's a server in the browser and does all the cool 
> things you mentioned above - and uses widgets to do it!).
> 
> The problem is not a standards one, I think. It's a problem that you think 
> other browser vendors have not bought into the whole widgets thing. Opera 
> supports W3C widgets, as do many other browser vendors. Maybe you should look 
> a little beyond the big browser vendors to "the long tail" - you will find 
> many companies actually implementing W3C widgets (did you know WinMobile 6.5, 
> Blackberry, Samsung, Nokia, etc. all do W3C widgets? that list is growing 
> little by little every day). That's pretty cool, I think!
> 
> Despite what you might think, getting only big browser vendors is not always 
> the aim of stuff that is done at the W3C. We make stuff for everyone to use 
> and innovate on. Who knows! maybe the next Big Company will be built on W3C 
> Widgets.

The nice thing about W3C Widgets is it gives you the flexibility to work in all 
kinds of ways. So I work on Apache Wookie[1] which implements W3C Widgets for 
web widgets served up using an application server. But you can take the same 
Widget out of Wookie and install it in a Samsung or a Blackberry to run direct 
on the device. Or use it in a desktop application like Widgeon. So you can 
offer users a lot of choices.

(Soon I'll be working on porting our W3C Widgets parser[2] to run in 
interactive whiteboards, which I'm pretty sure wasn't in our list of UCs!) 

[1] http://cwiki.apache.org/confluence/display/WOOKIE/
[2] 
http://cwiki.apache.org/confluence/display/WOOKIE/Using+Wookie%27s+W3C+Widget+Parser+in+other+Applications

Re: [widgets] Buggy P&C i18n Tests

[Scott Wilson]

Something else went strange with the tests - they have odd new names and url's 
that don't work:

E.g. 

Test "b5" has been renamed to: 

http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-RRZxvvTFHx/000/ta-rr-000.wgt

However the actual test widget is still at:

http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-RRZxvvTFHx/000/b5.wgt

Well, its clearly incorrect. However I would prefer not to have to go and 
manually retype all the URLs for my tests so if we can have the old names back 
that would be nice!


On 6 Sep 2010, at 12:54, Marcos Caceres wrote:

> 
> 
> On 9/6/10 12:25 PM, Scott Wilson wrote:
>> To be honest I've been having problems with the i18n test cases
>> generally. For example:
>> 
>> 
>> Tests that LRO direction applies to the name element. To pass, the
>> displayed value must render as "םפללחק".
>> 
>> 
>> I can't get the text in that config.xml to show as anything other
>> than "קחללפם" - even manually copying it into a HTML file with the
>> div attribute in every combination and opening in every browser I've
>> got (including Opera ;-) has the same result!
> 
> Yeah, we are working on it too. This is by no means easy. It's why the i18n 
> guys made us do it.
> 
> Try:
> 
>  
> "קחללפם"
> 
> Should work fine in all browsers.
> 
>> On 5 Sep 2010, at 23:24, Marcos Caceres wrote:
>> 
>>> 
>>> 
>>> On 9/4/10 4:54 PM, Scott Wilson wrote:
>>>> I'm also getting a Zip file error on the i18n-039&  040 sets
>>>> (these are the only ones I've implemented so far):
>>>> 
>>>> java.util.zip.ZipException: oversubscribed dynamic bit lengths
>>>> tree
>>>> 
>>>> They seemed to work OK earlier on yesterday, but seem to have
>>>> become recently corrupted. (They won't unzip using standard zip
>>>> desktop tools either)
>>> 
>>> Re-uploaded all the tests, and we fixed the borked tests too. Happy
>>> testing :)
>>> 
>>>> S
>>>> 
>>>> On 3 Sep 2010, at 19:55, Marcos Caceres wrote:
>>>> 
>>>>> Hi, Please be warned that following tests have some bugs. We
>>>>> will fix them next week.
>>>>> 
>>>>> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-lro/027/
>>>>> 
>>>>> 
> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-rlo/027/
>>>>> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-ltr/027/
>>>>> 
>>>>> 
> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-rtl/027/
>>>>> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-lro/028/
>>>>> 
>>>>> 
> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-rlo/028/
>>>>> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-ltr/028/
>>>>> 
>>>>> 
> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-rtl/028/
>>>>> 
>>>>> Effectively, the UA would reject the value of each because it
>>>>> is not a valid media type, so it would never be "displayed".
>>>>> 
>>>>> Also, "If the src attribute of the content element is absent or
>>>>> an empty string, then the user agent must ignore this element".
>>>>> This means that the tests above would not run at all because
>>>>> the UA would reject the content element (as they don't have a
>>>>> src attribute).
>>>>> 
>>>>> -- Marcos Caceres Opera Software
>>>>> 
>>>> 
>>> 
>>> -- Marcos Caceres Opera Software
>> 
> 
> -- 
> Marcos Caceres
> Opera Software

Re: [widgets] Buggy P&C i18n Tests

[Scott Wilson]

To be honest I've been having problems with the i18n test cases generally. For 
example:


Tests that LRO direction applies to the name element.
To pass, the displayed value must render as "םפללחק".


I can't get the text in that config.xml to show as anything other than "קחללפם" 
- even manually copying it into a HTML file with the div attribute in every 
combination and opening in every browser I've got (including Opera ;-) has the 
same result! 

On 5 Sep 2010, at 23:24, Marcos Caceres wrote:

> 
> 
> On 9/4/10 4:54 PM, Scott Wilson wrote:
>> I'm also getting a Zip file error on the i18n-039 & 040 sets (these are
>> the only ones I've implemented so far):
>> 
>> java.util.zip.ZipException: oversubscribed dynamic bit lengths tree
>> 
>> They seemed to work OK earlier on yesterday, but seem to have become
>> recently corrupted. (They won't unzip using standard zip desktop tools
>> either)
> 
> Re-uploaded all the tests, and we fixed the borked tests too. Happy testing :)
> 
>> S
>> 
>> On 3 Sep 2010, at 19:55, Marcos Caceres wrote:
>> 
>>> Hi,
>>> Please be warned that following tests have some bugs. We will fix them
>>> next week.
>>> 
>>> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-lro/027/
>>> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-rlo/027/
>>> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-ltr/027/
>>> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-rtl/027/
>>> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-lro/028/
>>> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-rlo/028/
>>> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-ltr/028/
>>> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-rtl/028/
>>> 
>>> Effectively, the UA would reject the value of each because it is not a
>>> valid media type, so it would never be "displayed".
>>> 
>>> Also, "If the src attribute of the content element is absent or an
>>> empty string, then the user agent must ignore this element". This
>>> means that the tests above would not run at all because the UA would
>>> reject the content element (as they don't have a src attribute).
>>> 
>>> --
>>> Marcos Caceres
>>> Opera Software
>>> 
>> 
> 
> -- 
> Marcos Caceres
> Opera Software

Re: [widgets] Buggy P&C i18n Tests

[Scott Wilson]

I'm also getting a Zip file error on the i18n-039 & 040 sets (these are the 
only ones I've implemented so far):

java.util.zip.ZipException: oversubscribed dynamic bit lengths tree

They seemed to work OK earlier on yesterday, but seem to have become recently 
corrupted. (They won't unzip using standard zip desktop tools either)

S

On 3 Sep 2010, at 19:55, Marcos Caceres wrote:

> Hi,
> Please be warned that following tests have some bugs. We will fix them next 
> week.
> 
> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-lro/027/
> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-rlo/027/
> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-ltr/027/
> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-rtl/027/
> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-lro/028/
> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-rlo/028/
> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-ltr/028/
> http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-rtl/028/
> 
> Effectively, the UA would reject the value of each because it is not a valid 
> media type, so it would never be "displayed".
> 
> Also, "If the src attribute of the content element is absent or an empty 
> string, then the user agent must ignore this element". This means that the 
> tests above would not run at all because the UA would reject the content 
> element (as they don't have a src attribute).
> 
> -- 
> Marcos Caceres
> Opera Software
> 

[widgets] error in test case: cx

[Scott Wilson]

Test case cx:

"Test the ability of the user agent to correctly process license element's href 
attribute when it is a file. To pass, the value of the widget license must be 
an empty string, but the license href attribute must point to the file at 
'test-license/pass.html'."

Config.xml:

http://www.w3.org/ns/widgets";>

cx

So either the test case needs to be "test-licene/pass.htm" or an "l" needs to 
be added in the config.xml

S

[widgets] Error in conformance test: dr

[Scott Wilson]

Test "DR" appears to be incorrect:

"Test the UA's ability to handle a feature element without a name attribute. To 
pass, the feature list must contain one feature named 'feature:a9bb79c1' whose 
required value is false."

The test widget contains the following config.xml:

http://www.w3.org/ns/widgets";>
ha

  



  




However, where the required attribute is missing from , a UA is 
expected to assume the value to be TRUE not FALSE:

Authoring Guidelines:
It is optional for authors to use the required attribute with an feature 
element. However, authors need to be aware that a user agent will behave as if 
the required attribute had been set to true when the required attribute is 
absent, meaning that the named feature needs to be available at runtime or the 
widget will be treated as an invalid widget package.



So I think this test case needs to be changed to either include a 
required="false" attribute, or to expect a value of "true" for "required" 
instead.

S

Re: [widgets] Widgets Updates

[Scott Wilson]

On 16 Aug 2010, at 21:29, Bernard Traversat wrote:

> On 8/16/10 2:34 AM, Rich Tibbett wrote:
>> 
>> On 14/08/2010 03:12, Bernard Traversat wrote:
>>> 
>>> Should we have a more explicit way to specify and notify users that some 
>>> updates may require data conversion and
>>> user data will be converted after the widget is updated? Due to the 
>>> error-prone nature of such conversion, users
>>> may want to back up their data before proceeding with an update.
>> 
>> I'm not sure I understand what you mean.
>> 
>> User data is not stored in a widget package itself. An update to an existing 
>> widget should be able to access the storage space used by previous versions 
>> of the same widget.
>> 
>> If data conversion is required perhaps you have a use case we could look at.
> The data conversion is the use case i was referring to. We should have a more 
> explicit way to tell the end-users upfront that by installing the new update
> his/her data will be converted with the potential risk of losing data and 
> never going back to the older version.

I think this UC is already covered by the Update Description Document; the 
widget author can put a warning in the details about the update, and the UA can 
then display that to the user. E.g.

http://www.w3.org/ns/widgets"; 
src="http://evil-fruit-company.com/sins/unoriginal-patent.wgt"; version="1.1">

  This update makes everything look really cool. Warning! This update will 
convert your existing data to a new format!



> 
> Hth,
> 
> B.
>> 
>> Regards,
>> 
>> Rich
> 

Re: [widgets] API - openURL security considerations

[Scott Wilson]

On 30 Jun 2010, at 14:30, Marcos Caceres wrote:

> I've evaluated the discussions in this thread and am strongly leaning
> towards proposing we drop openURL() from the specification on privacy
> and security grounds.
> 
> Although I can think of cases where it might be useful to have a
> widget programmatically call openURL (e.g., "when it's 5pm, and if I'm
> at home, sms these people and let him know 'I'm here, bring beer!'"),
> there are just too many abuse cases and complexities.

I haven't seen too many examples of OpenURL() in the wild, and in Wookie you 
may as well just use HTML  and window.open() as its running in a browser 
anyway. The UC would be for environments where window.open() was not handled by 
the UA; however implementing that would probably be better effort spent than 
implementing widget.openURL().

> I think we should follow Adam's advice from May 10 and just make URL
> handling reliant on a declarative model (i.e., leave it to HTML's a
> element and friends, as suggested by Adam below):
> 
>> 1) Remove the API and replace it with a declarative API, like a
>> hyperlink.  Remove the ability to programmatically click the hyperlink
>> and instead rely on the user actually clicking the link.  This
>> approach is related to the "browser button" element discussed in the
>> HTML working group for dealing with similar security issues with
>> programmatic access to other APIs.
> 
> I'm unsure if we should get HTML5 to specify this, or if we should
> specify this behavior (if they don't already). I personally think the
> widgets API spec would be overreaching if it started saying how URI
> handling in HTML should be done.
> 
>> 2) If we require an imperative API for following a hyperlink, restrict
>> the API to a whitelist of known-safe URL schemes.  We can allow user
>> agents to extend this list with a registry of known-safe URL schemes,
>> but we shouldn't allow access to random side-effecting schemes like
>> sms (to pick an example from the spec) by default.
> 
> I'm still thinking we could drop openURL for this version and then add
> it once we work out all the kinks and if developers really cannot live
> without it.

Sounds fine by me +1

> 
> 
> 
> 
> 
> 
> 
> On Tue, May 11, 2010 at 6:28 PM, Arthur Barstow  wrote:
>> Several responses to this thread were made by Thomas and Adam and since
>> those responses are not archived in a Public area, with their permission,
>> here are all of the responses, starting with the oldest.
>> 
>> The last Public response to this thread is:
>> 
>> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0465.html
>> 
>> -Art Barstow
>> 
>> 
>> ** From: w...@adambarth.com
>> Subject: Re: [widgets] API - openURL security considerations
>> Date: May 10, 2010 12:15:38 PM EDT
>> 
>> It's lame that we're using a blacklist instead of a whitelist here.
>> Also this recommendation is somewhat useless:
>> 
>> "it is recommended that the user agent prompt the user for
>> confirmation before passing the URI to a scheme handler"
>> 
>> It's unlikely that users will have much context for understanding the
>> consequences of this confirmation experience and hence will make poor
>> security decisions.
>> 
>> Personally, I think the API is poorly design and should be removed in
>> favor of something that is secure by design.  We're stuck with this
>> API in the web platform in the form of window.open(), but we'd be
>> better off without.  You can see all the machinations around popup
>> blockers and vulnerabilities that it has created.  Fpr example,
>> .
>> 
>> Adam
>> 
>> 
>> ** From: t...@w3.org
>> Subject: Re: [widgets] API - openURL security considerations
>> Date: May 10, 2010 3:21:07 PM EDT
>> 
>> On 10 May 2010, at 18:15, Adam Barth wrote:
>> 
>> 
>>> Personally, I think the API is poorly design and should be removed in
>>> favor of something that is secure by design.  We're stuck with this
>>> API in the web platform in the form of window.open(), but we'd be
>>> better off without.  You can see all the machinations around popup
>>> blockers and vulnerabilities that it has created.  Fpr example,
>>> .
>>> 
>> 
>> Are you suggesting to completely drop openURL from the widget API?  Or do
>> you suggest a redesign?
>> 
>> 
>> ** From: w...@adambarth.com
>> Subject: Re: [widgets] API - openURL security considerations
>> Date: May 10, 2010 3:36:11 PM EDT
>> 
>> On Mon, May 10, 2010 at 12:21 PM, Thomas Roessler  wrote:
>> 
>>> On 10 May 2010, at 18:15, Adam Barth wrote:
>>> 
 Personally, I think the API is poorly design and should be removed in
 favor of something that is secure by design.  We're stuck with this
 API in the web platform in the form of window.open(), but we'd be
 better off without.  You can see all the machinations around popup
 blockers and vulnerabilities that it has created.  Fpr example,
 

Re: Widget Updates Standard

[Scott Wilson]

Hi Christoph,

On 17 Jun 2010, at 14:26, Christoph Storm wrote:

> Hi,
> I am currently very busy reading your papers about W3C Widgets because I am 
> writing my master thesis about Widgets. The title is "Device interoperable 
> data visualization using standard W3C Widgets" - the important word is 
> "standard". Anyway, I really like your work and I am very excited how the 
> whole topic will evolve the next years.

Sounds interesting - do you think you can send me some more details offline? 
This might be relevant to an EU project I'm starting on soon.

> I have one question or recommendation regarding Widget Updates 
> (http://www.w3.org/TR/2010/WD-widgets-updates-20100413/). I really like the 
> idea of the "update-description" element in the config.xml file and the idea 
> of pointing to a UUD providing medat data - and here comes my question - 
> would it be possible to update content of a Widget through this technology as 
> well or is this update mechanism for the user agend update only?

My understanding is that this is an update for the Widget itself. However, as a 
widget is typically HTML+JS+CSS there isn't a hard distinction between code and 
content.

> Because it would be nice to have something like a push service that notifies 
> the client Widget when e.g. not only a new Widget package is available but 
> also when new content for an existing Widget is available. I think using or 
> extending the UUD to provide a link to updated content would match into this 
> topic. I think it would be an other reason for developers to use widgets, 
> e.g. on a mobile device when notification is integreated into the standard. 
> What do you think?

I think if the content is a significant part of the widget then it makes sense 
to use the widget updates facility.

For example, if the Widget is a "colouring book app" and the author creates 
some new pictures to colour in, then they can release a new update with a 
description of "Now with 25 more robot pictures to colour!" or somesuch. So 
this would be a "content" update using the Widget updates mechanism, and it 
would involve downloading and updating the widget package.

How the update is actually managed is up to the User Agent; the Widget instance 
itself would not typically access the UUD or receive update notifications from 
the UA. 

If the Widget wants to check an update site for new content that isn't an 
update of the widget package itself, then this could be done using AJAX to poll 
an update site on launch - this could follow the same format as the UUD, though 
that might be too limited. For example, a data visualization widget might look 
up a registry of services that it is compatible with.

I wonder if there is a specific use-case you can provide that isn't handled by 
these approaches?

> I hope that I am not completly wrong or missing anything that already 
> provides this service I am looking for within the Widget family of specs. 
> Anyway, I really appreciate all your comments regarding this topic and I am 
> very thankful that people like you working on standards for the web! It makes 
> life easier!
> 
> I am looking forward to your response. Thanks and best regards,
> christoph storm, austria
> 
> 

Cheers,

Scott

Re: [widgets] WARP testing

[Scott Wilson]

On 11 May 2010, at 15:58, Marcos Caceres wrote:

> On Tue, May 11, 2010 at 3:55 PM, Scott Wilson
>  wrote:
>> Hi Marcos,
>> 
>> I'll make a start on tests for the assertions about correctly processing the 
>> element (6-13).

I've checked in tests for ta-6 through ta-9.

>> I'm not sure about assertion 5, however  - how would you tell if it had been 
>> processed at an inappropriate point? What difference would it make? And how 
>> could you test it?
>> 
>> "Assertion ta-5: Secondly, a user agent MUST apply the rule for processing 
>> an access element at the appropriate point in the algorithm to process a 
>> configuration document: the appropriate point is where the algorithm allows 
>> for processing 'any other type of element' [[!WIDGETS]]." [1]
> 
> Tests would be having an access element at the top, middle, and end of
> the document and also making sure that it does not get processed when
> nested inside another element.
> 
> so 1:
> 
> 
> 
> 
> 
> 2:
> 
> 
> 
> 
> 
> 3:
> 
> 
> 
> 
> 

So presumably the access element is ignored in cases 2 & 3, even if the element 
itself is valid? I'm not sure if that's such a great idea for interoperability.

Unless of course it is processed, just after processing the P&C elements, which 
has no discernible effect on the processed widget and doesn't really make it 
testable.

Maybe I'm just missing something here!

> 4: (which would cause it to be ignored)
> 
> 
> 

OK, I'll make a test for that case.

> 
> 
> 
> 
>> [1] http://dev.w3.org/2006/waf/widgets-access/test-suite/
>> 
>> S
>> 
>> On 4 May 2010, at 15:23, Marcos Caceres wrote:
>> 
>>> On Thu, Apr 1, 2010 at 8:55 PM, Scott Wilson
>>>  wrote:
>>>> Wookie has implemented WARP, so we can try out the tests as soon as they 
>>>> are
>>>> available.
>>> 
>>> I'm seriously not getting the cycles to do this. Scott, any chance you
>>> could help us out?
>>> 
>>> According to [1], there is only around 15 assertions... that roughly
>>> equates to 45 tests.
>>> 
>>> Kind regards,
>>> Marcos
>>> 
>>> [1] http://dev.w3.org/2006/waf/widgets-access/test-suite/
>>> 
>>> --
>>> Marcos Caceres
>>> Opera Software ASA, http://www.opera.com/
>>> http://datadriven.com.au
>> 
>> 
>> 
> 
> 
> 
> -- 
> Marcos Caceres
> Opera Software ASA, http://www.opera.com/
> http://datadriven.com.au

Re: [widgets] WARP testing

[Scott Wilson]

Hi Marcos,

I'll make a start on tests for the assertions about correctly processing the 
element (6-13).

I'm not sure about assertion 5, however  - how would you tell if it had been 
processed at an inappropriate point? What difference would it make? And how 
could you test it?

"Assertion ta-5: Secondly, a user agent MUST apply the rule for processing an 
access element at the appropriate point in the algorithm to process a 
configuration document: the appropriate point is where the algorithm allows for 
processing 'any other type of element' [[!WIDGETS]]." [1]

[1] http://dev.w3.org/2006/waf/widgets-access/test-suite/

S

On 4 May 2010, at 15:23, Marcos Caceres wrote:

> On Thu, Apr 1, 2010 at 8:55 PM, Scott Wilson
>  wrote:
>> Wookie has implemented WARP, so we can try out the tests as soon as they are
>> available.
> 
> I'm seriously not getting the cycles to do this. Scott, any chance you
> could help us out?
> 
> According to [1], there is only around 15 assertions... that roughly
> equates to 45 tests.
> 
> Kind regards,
> Marcos
> 
> [1] http://dev.w3.org/2006/waf/widgets-access/test-suite/
> 
> -- 
> Marcos Caceres
> Opera Software ASA, http://www.opera.com/
> http://datadriven.com.au

Re: [widgets] WARP default policy

[Scott Wilson]

On 5 May 2010, at 10:40, Robin Berjon wrote:

> On May 4, 2010, at 19:29 , Scott Wilson wrote:
>> I've just been reading through the WARP spec again, and in particular this 
>> stood out:
>> 
>> In the default policy, a user agent must deny access to network resources 
>> external to the widget by default, whether this access is requested through 
>> APIs (e.g. XMLHttpRequest) or through markup (e.g. iframe, script, img).
>> 
>> I'm not sure if this statement is actually helpful here. While it makes 
>> sense that WARP defines policies that widen access beyond whatever the UA's 
>> default policy may be, is it strictly necessary to define the default 
>> policy? 
> 
> Well, if you think about it a little bit further, is it really necessary to 
> have a way of defining a network access policy, and if so is the content 
> you're distributing the best place to do so? I personally have a somewhat 
> reserved judgement about whether WARP is useful at all. A rather large number 
> of people expressed this requirement, so it was delivered, and it's quite 
> possible that they were right. But it's also possible that they're not which 
> is why I'm happy that it's not part of P+C.
> 
> If you noticed this because you're working on it for Wookie, I'm not sure 
> that's it's worth the (minimal) effort. WARP makes no sense in a Web context.

We use it to feed the whitelist our server-side proxy service uses; I've 
already implemented it for this admittedly limited purpose in Wookie and it 
seems to work fine.  But for the most part access policy is dealt with by the 
browser security model, which is moving towards making such workarounds 
unnecessary in the long run. However, right now we still have a limited UC for 
WARP.

> 
> -- 
> Robin Berjon - http://berjon.com/
> 
> 
> 

[widgets] WARP default policy

[Scott Wilson]

I've just been reading through the WARP spec again, and in particular this 
stood out:

In the default policy, a user agent must deny access to network resources 
external to the widget by default, whether this access is requested through 
APIs (e.g. XMLHttpRequest) or through markup (e.g. iframe, script, img).

I'm not sure if this statement is actually helpful here. While it makes sense 
that WARP defines policies that widen access beyond whatever the UA's default 
policy may be, is it strictly necessary to define the default policy? 

For example, this implies that a UA should actively block widgets using JSONp, 
CORS,  Google's Ajax libraries, CDNs, or even a widget just grabbing its 
company's icon off their website in an img tag. 

Now there may be UAs who have a default policy that is this strict, but 
requiring this to be the default policy as a conformance requirement for any 
WARP implementation seems OTT.

S

[widgets] W3C Widgets on Android (was:Zip vs GZip Tar)

[Scott Wilson]

On 4 May 2010, at 10:14, Marcos Caceres wrote:

> Hi Scott,
> 
> On Sat, May 1, 2010 at 10:14 AM, Scott Wilson
>  wrote:
>> On 30 Apr 2010, at 18:46, Ian Fette (イアンフェッティ) wrote:
>> 
>> Marcos, Chaals, fair points. I can't honestly say that we are looking to
>> implement this spec at this point,
>> 
>> I saw a very nice W3C Widgets implementation on Android the other day ;-)
> 
> Great! can you let us know what it was so we can add it to our
> implementations list.

It was a version of the Aplix WRT platform already on the list - Anselm gave a 
demo of it integrated into Android at the London Android meetup. Very nice 
though - W3C widgets on the home screen, or deployed in the same way as regular 
Android apps, or within the Aplix widget manager app.

S

Re: [widgets] Zip vs GZip Tar

[Scott Wilson]

On 30 Apr 2010, at 18:46, Ian Fette (イアンフェッティ) wrote:

> Marcos, Chaals, fair points. I can't honestly say that we are looking to 
> implement this spec at this point,

I saw a very nice W3C Widgets implementation on Android the other day ;-)

> and certainly I am not the type to raise a formal objection, so please don't 
> misinterpret this as "I think this spec needs to go back to an earlier stage 
> in the formal process." I also understand that once things start to ship in 
> implementations, they are harder to change. I guess what irked me was that 
> there was what I saw as a valid point being raised and dismissed. I do think 
> that having a packaged format that is streamable would be useful, especially 
> if you wanted to host these widgets inside of any container / page that may 
> load the widgets dynamically (e.g. iGoogle as an example of a web page 
> loading what are essentially widgets). I would agree that given your existing 
> implementors and the use cases they are targeting, it is likely not important 
> enough to cause strife to existing implications and cause them not to work. 
> My hope was that perhaps it could be considered and a backwards-compatible 
> mechanism could be found. e.g. today browsers and servers negotiate what 
> encodings they accept, one could imagine a similar negotiation taking place 
> prior to whatever widget is there being served up. I think it is something to 
> consider, at the very least for v2.

Certainly sounds like an interesting UC for v2 

> 
> -Ian
> 
> Am 30. April 2010 10:31 schrieb Marcos Caceres :
> 
> 
> On 30/04/10 6:36 PM, Ian Fette (イアンフェッティ) wrote:
> Am 30. April 2010 00:26 schrieb Marcos Caceres  >:
> 
> 
> 
>Hi Ian,
> 
>On Apr 30, 2010, at 8:09 AM, Ian Fette (イアンフェッティ)
>mailto:ife...@google.com>> wrote:
> 
>Disclaimer: I really don't care about this particular spec given
>the politics and think that it is likely not to go anywhere as-is.
>So take my feedback for what it's worth.
> 
>I don't know who is feeding you ideas about "politics", but there is
>nothing contraversial about the Widget specs. If you know something
>I don't, then please tell us. Also, last I checked there were over
>40 companies backing widgets. Just because Google ain't backing them
>right now does not mean they are going nowhere.
> 
> 
>This is not bikeshedding, nor are many of the previous threads
>that have brought up issues with this spec and body of work in
>general. This is not "I prefer my favorite random compression
>algorithm," this is "a serious performance issue is caused for
>loading any large widget that is packed in such a manner because
>we can't do anything until the entire file is downloaded."
> 
>If this was true, then why does chrome  use Zip for browser
>extensions? They are almost exactly the same as W3C widgets in every
>way.
> 
> 
> Because
> a) there's not a sense of starting to render an extension before it's
> installed,
> b) and it's installed or not installed atomically.
> c) they are installed and updated in the background, not necessarily
> embedded on a page
> 
> I would say widgets are as above, but...
> 
> 
> On the other hand, a widget on a page could certainly be rendered
> optimistically.
> 
> But this is also true. Though required s in the widget config 
> document could cause a widget to be treated as unsupported. So streamability 
> would only work for a particular subset of widgets.
> 
> 
>Maybe some people don't care about performance, and if a lack of
>concern for performance is part of the use cases, then such a
>decision is perfectly valid according to the use cases.
> 
>We care about making a generic packaging format that everyone can
>make (not just people on *nix).
> 
> 
> And I was not advocating for a specific algorithm, I was objecting to
> someone taking a valid criticism with technical backing and calling it
> bikeshedding.
> 
> I agree with you. I don't think this is a bikeshedding discussion either. 
> Lets talk more about use cases and requirements.
> 
> 
> fwiw though, taking tar/gzip as an example, it is not exactly hard for a
> web author to deal with a tar file.
> 
> It's no more difficult than installing a browser I guess. I won't say "the 
> tools will save us".
> 
> 
>Google has been actively encouraged to participate in this work from
>the beginning. It's not our fault Google didn't want to contribute
>this as a use case.
> 
> 
> No, it's not. That doesn't mean that valid criticisms should be
> dismissed as bikeshedding, or that people should cling to a notion of
> being "too late". We aren't clinging to Gears saying it's too late,
> we're not even really clinging to Web SQL DB - we are actively moving
> forward on Web Indexed DB and are very involved in discussions on how to
> improve the offline storage situation. So, frankly, I really don't buy
> the "it's too late" argum

Re: can we develop a w3c widget engine for the webkit?

[Scott Wilson]

On 16 Apr 2010, at 09:37, Robin Berjon wrote:

> Hi,
> 
> On Apr 16, 2010, at 04:44 , 126.com wrote:
>>now there are many w3c widget engine versions has been developed,but it 
>> almost develped with java base on JAVAVM, whether or not we can building a 
>> w3c widget engine written with c/c++ language which as a plugin of webkit.
> 
> If you're asking if it's possible to develop a W3C Widget engine based on 
> WebKit, the answer is yes. You can use any Web runtime engine. I'm not sure 
> but I think that using WebKit for this has actually been done, but I forget 
> the details.

Aplix's WebVM is implemented in this fashion, as a webkit plugin in C:

http://wiki.webvm.net/wrtc/

> 
> -- 
> Robin Berjon - http://berjon.com/
> 
> 
> 
> 

Re: i18n comments: (was: [widgets] Span example)

[Scott Wilson]

On 6 Apr 2010, at 15:08, Marcos Caceres wrote:
> 
> For the sake of record keeping, the above has been integrated into the
> schema with the addition of the overrides:
> 
> http://dev.w3.org/2006/waf/widgets-schema/common.rnc
> 
> The spec also reflects this:
> http://dev.w3.org/2006/waf/widgets/#the-dir-attribute

Is it just my eyes or are "lro" and "rlo" in a bigger font than "ltr" and "rtl"?

> 
> 
> -- 
> Marcos Caceres
> http://datadriven.com.au
> 

[widgets] WARP testing

[Scott Wilson]

Wookie has implemented WARP, so we can try out the tests as soon as they are 
available.

On 1 Apr 2010, at 16:14, Arthur Barstow wrote:

> The draft minutes from the April 1 Widgets voice conference are available at 
> the following and copied below:
> 
> http://www.w3.org/2010/04/01-wam-minutes.html
> WARP spec: test suite status
> 
>   AB: what is the status of the WARP test suite (
>   [23]http://dev.w3.org/cvsweb/2006/waf/widgets-access/test-suite/ )?
> 
> [23] http://dev.w3.org/cvsweb/2006/waf/widgets-access/test-suite/
> 
>   RB: nothing recent from me
> 
>   MC: nothing recent from me either
>   ... the spec has been marked-up for testing
>   ... just need the tests
>   ... I'd like to move this to CR as quickly as possible
>   ... and I don't think we need a test suite before publishing the CR
> 
>   RB: I'm fine with that as well
> 
>   AB: any other comments about going to CR now?
> 
>   [ No ]
> 
>ACTION: barstow add proposal to move WARP spec to CR to
>   April 8 agenda [recorded in
>   [24]http://www.w3.org/2010/04/01-wam-minutes.html#action01]
> 
>Created ACTION-513 - Add proposal to move WARP spec to CR
>   to April 8 agenda [on Arthur Barstow - due 2010-04-08].

Re: [widgets] Span example

[Scott Wilson]

All,

I think the  and dir models work well. I've implemented the new 
algorithms in Wookie for License, Name, Author and Description, and they seem 
to work nicely[1]. I'll add the same functionality to the Widget root element 
as the next step.

When the test cases have documentation I'l add them to our test suite and see 
if we can pass them.

-S

[1] 
Source:
http://svn.apache.org/repos/asf/incubator/wookie/trunk/parser/java/src/org/apache/wookie/w3c/impl/AbstractLocalizedEntity.java

JUnit Tests:
http://svn.apache.org/repos/asf/incubator/wookie/trunk/parser/java/src-test/org/apache/wookie/w3c/test/DirectionalityUtilsTest.java
http://svn.apache.org/repos/asf/incubator/wookie/trunk/parser/java/src-test/org/apache/wookie/w3c/test/LocalizedContentTest.java

On 19 Mar 2010, at 11:49, Arthur Barstow wrote:

> Richard, Addison, Felix, All,
> 
> Based on my conversations with Marcos and reading this thread, it is my 
> understanding that you support:
> 
> a) the new  element and dir attribute model Marcos added to the Widget 
> P&C spec [P&C-ED] and consequently,
> 
> b) the removal of the ITS references that were in the December CR [P&C-CR].
> 
> Would you please confirm this or if my understanding is not correct, please 
> elaborate on any remaining issues?
> 
> Also, if you have any feedback on the 60 related test cases Marcos created, 
> please reply to the thread he used to announce those test cases:
> 
> [widgets] dir and span tests
> http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0845.html
> 
> -Thanks, Art Barstow
> 
> [P&C-ED] http://dev.w3.org/2006/waf/widgets/
> [P&C-CR] http://www.w3.org/TR/2009/CR-widgets-20091201/
> 
> 
> On Mar 16, 2010, at 3:15 PM, ext Marcos Caceres wrote:
> 
>> Hi Richard,
>> 
>> Added the example at:
>> http://dev.w3.org/2006/waf/widgets/#span
>> 
>> Please see also the examples for the dir attribute:
>> http://dev.w3.org/2006/waf/widgets/#dir
>> 
>> Thanks again for all your time and help!
>> 
>> On Tue, Mar 16, 2010 at 7:58 PM, Richard Ishida  wrote:
>>> [This is a continuation of one part of the 
>>> http://lists.w3.org/Archives/Public/public-i18n-core/2010JanMar/0043.html 
>>> thread.]
>>> 
>>> It addresses the comment:
>>> 
>>> [[  7.16. The span Element  
>>> http://dev.w3.org/2006/waf/widgets/#the-span-element-and-its-attributes
>>> [2] I think the example could be improved by having something inside the 
>>> span with punctuation (eg. exclamation mark) or such, and maybe the 
>>> description should be in English - otherwise you'd probably want to put the 
>>> dir on the widget tag and have English in the span. Should I try to find 
>>> another example ?
>>> ]] at http://www.w3.org/International/reviews/0907-widgets-pc/
>>> 
>>> 
>>> Here's my proposed example (thanks to Aharon Lanin for helping with the 
>>> Hebrew).  I made up something that might appear in a Hebrew widget, rather 
>>> than an English one, since it's a little more realistic.
>>> 
>>> >> xmlns="http://www.w3.org/ns/widgets";
>>> xml:lang="he" dir="rtl">
>>> GPS Weather!
>>> >>  יישומון ה-GPS Weather! מאפשר לך לבדוק 
>>> את מזג האוויר בכל נקודת GPS ברחבי העולם.
>>> 
>>> 
>>> 
>>> Here's a version ready to drop into HTML (I suggest you copy it as a unit, 
>>> to avoid problems with the bidirectional text.)
>>> 
>>> >> xmlns="http://www.w3.org/ns/widgets";
>>> xml:lang="he" dir="rtl">
>>> GPS Weather!
>>> >>  יישומון ה-GPS 
>>> Weather! מאפשר לך לבדוק את מזג האוויר בכל נקודת GPS ברחבי 
>>> העולם.
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> Marcos Caceres
>> http://datadriven.com.au
>> 
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

[widgets] Apache Wookie's W3C Widget parser now available as standalone Java library

[Scott Wilson]

Hi everyone,

You may be interested to know that we've extracted the W3C Widget  
parsing engine used in Wookie as a standalone Java library that can be  
used in other projects and products. The library can be used to parse  
and unpack W3C Widgets into local directories and work with processed  
Widget package information such as localized icons and start files etc.


There are instructions on how to build and use it here:

http://cwiki.apache.org/confluence/display/WOOKIE/Using+Wookie%27s+W3C+Widget+Parser+in+other+Applications

S




smime.p7s
Description: S/MIME cryptographic signature

Re: [widgets] Request for Comments: LCWD of Widget Access Request Policy spec; deadline 13-Jan-2010

[Scott Wilson]

I've included an implementation of the WARP draft in the current  
Apache Wookie (incubating) snapshot if anyone fancies playing with it.  
Its missing a management UI, but you can drop .wgt files in the Wookie  
deploy folder and it will process the access request policy.


E.g.
 Adding "weather.wgt" with:
http://www.bbc.co.uk/weather/feeds/rss"/>

 Outputs:
 [java]  INFO [Thread-13] (WidgetFactory.java:213) - access  
policy granted for Weather to access http://www.bbc.co.uk
 [java] 15:38:44,495  INFO ContextListener:176 - Weather - Widget  
was successfully imported into the system.


S

On 4 Mar 2010, at 17:17, Marcos Caceres wrote:

For the sake of the disposition of comments, I consider my comments  
disposed of (in a good way) :)


Kind regards,
Marcos

On 4/03/10 4:28 PM, Robin Berjon wrote:

Hi Marcos,

On Dec 21, 2009, at 16:06 , Marcos Caceres wrote:
An access request is a request made by an author to the user  
agent for

the ability to retrieve one or more network resources. The network
resources and author requests to access are identified using access
elements in the widget's configuration document.


I gots me confused by the second sentence, maybe change to:

"Requests by an author to access network resources can be identified
by the presence of access elements in the widget's configuration  
document."


Sounds just as confused to me. How about:

"Access element in the widget's configuration document express the  
author's requests to access network resources."


?


Good enough.


3. Conformance
This specification defines conformance criteria that apply to a  
single
product: user agents that implement the interfaces that it  
contains.


It's confusing to talk about "interfaces" here, though I understand
you are talking about interfaces in general terms. I would prefer if
the spec just said:

"This specification defines conformance criteria that apply to a  
single

product: user agents."

And a "user agent" be defined as "a software application that
implements this specification and the [WIDGETS] specification and  
it's

dependencies."


Okay.

A user agent enforces an access request policy. In the default  
policy,

a user agent must deny access to network resources external to the
widget by default, whether this access is requested through APIs  
(e.g.

XMLHttpRequest) or through markup (e.g. iframe, script, img).


i think you need to make it really clear that you've just defined  
the
"default policy" for a WUA. Please make it a sub-section or  
something.


A subsection seems overkill for a single sentence. I'll split it  
into its own paragraph and make sure it's a dfn.


Ok.


The exact rules defining which execution scope applies to network
resources loaded into a document running in the widget execution  
scope

depend on the language that is being used inside the the widget.


Typo: "the the"


Okay.



5. The access Element
Context in which this element may be used:


P&C uses "Context in which this element is used:". It would be  
nice if

this one said the same thing :)


Okay!


Great.


5.1 Attributes

origin
An IRI attribute that defines the specifics of the access request  
that

is requested.


"that is requested" seems tautological... and makes the sentence  
read

funny (and not "ha ha" funny.)


I'll make it "that is made".

"Additionally, an author can use the special value of U+002A  
ASTERISK (*):"


Okay.


This special value provides a means for an author to
request from the user agent unrestricted access to network  
resources.


Break here.


It's HAMMERTIME!


(Oh-oh-oh-oh-oh-oh-oh-oh-oh-oh-oh-oh)


Only the scheme and authority components can be present in the IRI
that this attribute contains ([URI], [RFC3987]).


I'm really sorry, I'm having a hard time parsing the above sentence.
At first, I thought it was related to the sentence about "*". Can  
you

change the order of these sentences above. Also, the "*" value is
pretty important, maybe it deserves it's own sub-section even if it
just contains one short paragraph. i'm sure people will come back
asking for clarification once we go to CR as to how it's supposed to
work.


I'll split and clarify.


subdomains
A boolean attribute that indicates whether or not the host  
component

part of the access request applies to subdomains of domain in the
origin attribute.


It should be clear that "subdomains" and "domain" here refers to
components of RFC-such-and-such, right?


Yup, adding a reference to RFC 1034.


The default value when this attribute is absent is
false, meaning that access to subdomains is not requested.


what does it means when I have:

http://foo.bar.woo.com"; subdomains="true"/>

Everything before "woo.com" is allowed, right? Maybe could be  
clear in

the spec for people like me :)


Err no, everything below foo.bar.woo.com. Maybe after reading RFC  
1034 it'll be clearer?


"""
A domain is a subdomain of another domain if it
is contained within that domai

Re: [widgets] dir and span elements

[Scott Wilson]

On 2 Mar 2010, at 11:28, Marcos Caceres wrote:


On 1/03/10 11:47 PM, Phillips, Addison wrote:


Thanks Addison - and yes, I think this makes a lot of sense for a
"content"-style spec like HTML, however as the Widgets P&C is a
configuration document most of which is IRIs, integers and so on
rather than text content its less of a clear case.



No, I understand and don't disagree. However, there is something to  
be said for making it an attribute of, for example. Then  
you could have an override of directionality only when a given  
element has a different base direction. In the example in the spec  
[1], consider how this might be cleaner:

[...]

I'm not suggesting that 'dir' makes sense everywhere, but there is  
some utility in allowing direction (and maybe language/locale??) in  
at the outermost element?



If dir conformance is tested in relation to the Rule For Obtaining
Text Content then this already scopes its use to the four elements
mentioned as these are the only elements that the rule applies to.



I agree, but there is one more potential case. The   
element could have a default base directionality set  
(each  target or localized equivalent might also override  
it).


I agree that a scoped 'dir' attribute is a pain to deal with  
implementation-wise, so I personally would be open to not doing  
this. But I think it worth considering.




Just to clarify the rationale for the way dir and span are  
specified... Wrt global dir, although potentially painful, it serves  
as a useful extension point if we add new elements in the future.  
Addison also demonstrated the use case we had in mind above when we  
made it global. Scott raised some valid issues (i.e., not all  
attributes are supposed to be, um, "bidi'ed"), but ones intended for  
human consumption most certainly are (e.g., the short name).


With respect to , I decided not to tie its use to any element  
(i.e., it can be declared inside any element). The primary reason is  
extensibility in case we decide to add new metadata elements. As  
Scott pointed out, how each element is processed is inherently tied  
to Step 7, so the specification makes it clear when a span element  
would be
ignored or processed as part of "9.1.7. Rule for Getting Text  
Content" [1].


OK, I think allowing a global dir attribute and span element, but for  
conformance purposes implementers only having to deal with cases where  
the Rule for Getting Text Content is applied is a reasonable balance  
between future-proofing and YAGNI[1].



So, the questions that remain are:

1. In Step 7 [2], what modifications need to be made in order to  
accommodate dir as a global attribute and as a local attribute?


2. In "Rule for Getting Text Content", what modifications do we need  
to make (if any) to accommodate dir as a global attribute.


Well, the current text doesn't seem to be right:

"If input has a dir attribute, or has any child elements that contain  
a dir attribute, then process input and its descendant text nodes in  
accordance to the [Widgets-Bidi] specification and return the  
resulting string."


Instead it should be something like:

"If input has a dir attribute, or has any child elements that contain  
a dir attribute, or has any parent elements that contain a dir  
attribute, then process input and its descendant text nodes in  
accordance to the [Widgets-Bidi] specification and return the  
resulting string."


The short name attribute case isn't covered here, but instead uses the  
Rule for Getting a Single Attribute Value[2]. Looking at this it would  
seem that short="looc" would work OK as the  
rule doesn't require removing tags in the attribute value. Though it  
may be useful having a test case for it in any case.


[1] http://en.wikipedia.org/wiki/YAGNI
[2] http://dev.w3.org/2006/waf/widgets/#rule-for-getting-a-single-attribute-valu


Kind regards,
Marcos

[1] http://dev.w3.org/2006/waf/widgets/#rule-for-getting-text-content
[2] http://dev.w3.org/2006/waf/widgets/#algorithm-to-process-a-configuration-doc




smime.p7s
Description: S/MIME cryptographic signature

Re: [widgets] dir and span elements

[Scott Wilson]

On 1 Mar 2010, at 17:58, Phillips, Addison wrote:


Hi Scott,

One reason to make 'dir' available on higher-level elements is that  
'dir', like 'xml:lang', has scope. It is often useful to specify a  
"base" directionality for an entire document or block of elements  
rather than having to repeat it over-and-over on each affected  
element. I can agree that it might not make sense on every element  
and perhaps we should look at which structural elements in P&C make  
sense as a place to set a base directionality or directionality  
override.


Thanks Addison - and yes, I think this makes a lot of sense for a  
"content"-style spec like HTML, however as the Widgets P&C is a  
configuration document most of which is IRIs, integers and so on  
rather than text content its less of a clear case.


If dir conformance is tested in relation to the Rule For Obtaining  
Text Content then this already scopes its use to the four elements  
mentioned as these are the only elements that the rule applies to.


I also agree about making  available inside . In  
fact, it is probably the *most* useful inside the license element.


Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.



-Original Message-
From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core-
requ...@w3.org] On Behalf Of Scott Wilson
Sent: Monday, March 01, 2010 9:44 AM
To: marc...@opera.com
Cc: public-webapps; public-i18n-c...@w3.org
Subject: Re: [widgets] dir and span elements

Hi Marcos,

On 26 Feb 2010, at 17:44, Marcos Caceres wrote:


Hi i18n WG,
I've added the dir attribute and span elements to the Widgets P&C
Specification, as well as a bunch of examples (which are wrong,

so I

would really appreciate some help with these!).

The dir attribute is specified here:
http://dev.w3.org/2006/waf/widgets/#global-attributes

The span element is specified here:
http://dev.w3.org/2006/waf/widgets/#the-span-element

The processing step that defers to the yet to be written [WIDGET-

BIDI]

specification is defined here:
http://dev.w3.org/2006/waf/widgets/#rule-for-getting-text-content

The specification makes it mandatory that a user agent implement

the

WIDGET-BIDI spec:

"A user agent is an implementation of this specification that

also

supports [XML], [XMLNS], [UTF-8], [DOM3CORE], [SNIFF], [WIDGETS-

BIDI],

and [ZIP]..."

We would appreciate your review and any assistance you can

provide.

In particular, we would appreciate your guidance into what would

go

into the Widgets Bidi specification (i.e., how processing is done

for

dir and span). At the moment, we only have the following text for

such

a specification (based on HTML5's bdo element):

[[
If an element has the dir attribute set to the exact value ltr,

then

for the purposes of the bidi algorithm, the user agent must act

as if

there was a U+202D LEFT-TO-RIGHT OVERRIDE character at the start

of

the element, and a U+202C POP DIRECTIONAL FORMATTING at the end

of the

element.

If the element has the dir attribute set to the exact value rtl,

then

for the purposes of the bidi algorithm, the user agent must act

as if

there was a U+202E RIGHT-TO-LEFT OVERRIDE character at the start

of

the element, and a U+202C POP DIRECTIONAL FORMATTING at the end

of the

element.

The requirements on handling the span element for the bidi

algorithm

may be implemented indirectly through the style layer.
]]


I can live with this, with a few comments:

1. "dir" is now an (optional?) attribute of every element; however,
previously its usage was limited to elements that contain human-
readable text content: , , , and
.
Is there a reason for making it global in this manner? E.g. would
it
not make more sense to specify "dir" attributes on these four
specific
P&C elements? I don't see anyone putting "dir" on (e.g.) the height
attribute, nor would we want to include a test for it for
compliance
with optional spec features.

2. "span" should be allowed as a child element of the 
element as well as for ,  and .



Thanks again for all your time and help!

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







smime.p7s
Description: S/MIME cryptographic signature

Re: [widgets] dir and span elements

[Scott Wilson]

Hi Marcos,

On 26 Feb 2010, at 17:44, Marcos Caceres wrote:


Hi i18n WG,
I've added the dir attribute and span elements to the Widgets P&C
Specification, as well as a bunch of examples (which are wrong, so I
would really appreciate some help with these!).

The dir attribute is specified here:
http://dev.w3.org/2006/waf/widgets/#global-attributes

The span element is specified here:
http://dev.w3.org/2006/waf/widgets/#the-span-element

The processing step that defers to the yet to be written [WIDGET-BIDI]
specification is defined here:
http://dev.w3.org/2006/waf/widgets/#rule-for-getting-text-content

The specification makes it mandatory that a user agent implement the
WIDGET-BIDI spec:

"A user agent is an implementation of this specification that also
supports [XML], [XMLNS], [UTF-8], [DOM3CORE], [SNIFF], [WIDGETS-BIDI],
and [ZIP]..."

We would appreciate your review and any assistance you can provide.
In particular, we would appreciate your guidance into what would go
into the Widgets Bidi specification (i.e., how processing is done for
dir and span). At the moment, we only have the following text for such
a specification (based on HTML5's bdo element):

[[
If an element has the dir attribute set to the exact value ltr, then
for the purposes of the bidi algorithm, the user agent must act as if
there was a U+202D LEFT-TO-RIGHT OVERRIDE character at the start of
the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the
element.

If the element has the dir attribute set to the exact value rtl, then
for the purposes of the bidi algorithm, the user agent must act as if
there was a U+202E RIGHT-TO-LEFT OVERRIDE character at the start of
the element, and a U+202C POP DIRECTIONAL FORMATTING at the end of the
element.

The requirements on handling the span element for the bidi algorithm
may be implemented indirectly through the style layer.
]]


I can live with this, with a few comments:

1. "dir" is now an (optional?) attribute of every element; however,  
previously its usage was limited to elements that contain human- 
readable text content: , , , and .  
Is there a reason for making it global in this manner? E.g. would it  
not make more sense to specify "dir" attributes on these four specific  
P&C elements? I don't see anyone putting "dir" on (e.g.) the height  
attribute, nor would we want to include a test for it for compliance  
with optional spec features.


2. "span" should be allowed as a child element of the   
element as well as for ,  and .




Thanks again for all your time and help!

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





smime.p7s
Description: S/MIME cryptographic signature

Re: [widgets] ITS in Widgets

[Scott Wilson]

On 22 Feb 2010, at 18:11, Marcos Caceres wrote:


Dear i18n core,

I'm writing on behalf of the Web Apps WG about the possibility of  
conducting a joint teleconference to discuss some issues with the  
ITS [1] features in the Widgets 1.0 Family of Specifications.


Basically, we would like to discuss:

1. Moving ITS functionality out of the Widgets Packaging and  
Configuration specification to a separate specification.


2. Clarifying some aspects of how content that uses ITS  
functionality is processed, so to address an API issue that is  
discussed below.


As you may recall, the WebApps WG collaborated with i18n to  
integrate ITS functionality into the Widgets Packaging and  
Configuration (P&C) specification [2]: namely, the   
element and its:dir attribute. We now have approximately 10 vendors  
claiming to implement P&C. Unfortunately, we have not managed to get  
a single vendor to implement the ITS features; and, as far as we  
know, none of these implementations intend to implement the ITS  
features.


As I understood it there is the its:span element and/or the its:dir  
attribute.


Many P&C elements can have an its:dir attribute, and we've implemented  
all of these though not yet all consistently. For example, if you set  
its:dir on license, then you'll get that info in the Wookie widget  
catalogue with ITS attribute, but we haven't ensured that the same is  
true for description and longname (though this mail has reminded me to  
go and fix it...)


The its:span element is trickier as its an exception then to the  
general rules for processing content in P&C and requires special  
handling as it would be the only case where markup is allowed inside  
content.


The lack of commitment by vendor's to support the ITS specification  
in the P&C specification is blocking us from progressing the P&C to  
Proposed Recommendation. We must state that this is not a criticism  
of ITS, and we are unclear as to why implementers are choosing not  
to support it. Vendors have indicated that they do, however, support  
the appropriate Unicode characters to control directionality.


As we are fully committed to having a suitable i18n solution for  
P&C, the Web Apps working group would like to co-ordinate with i18n  
to address this issue at the markup level. We want to discuss the  
creation of a new specification that would add the span/dir  
functionality in the widget namespace. We are only proposing this  
because various members (Opera included) have expressed that they  
would be more willing to implement the ITS functionality if it was  
defined in the widget namespace.


The working group has also identified a potential issue with how ITS  
data is passed to one of our APIs [3]. The issue of accessing ITS  
marked-up content through an API is important, as currently if one  
has Foo esrever Bar, one gets a  
string back in the API that loses the direction information. The Web  
Apps Working Group believes that an orthogonal specification could  
address this issue.


I think solving this issue may resolve others, as you then have a  
reason for parsing the ITS information correctly in the P&C stage and  
can more readily demonstrate functionality for it.




Although short notice, it would be helpful if members from the i18n  
WG could join our weekly teleconf taking place on Feb 25 (starts at  
3pm Paris time). We will send the agenda to this list on the 24th.


Kind regards,
Marcos

[1] http://www.w3.org/TR/its/
[2] http://www.w3.org/TR/widgets/
[3] http://www.w3.org/TR/widgets-apis/





smime.p7s
Description: S/MIME cryptographic signature

Re: [widgets] API - openURL security considerations

[Scott Wilson]

On 18 Feb 2010, at 21:52, Arve Bersvendsen wrote:

On Thu, 18 Feb 2010 22:09:00 +0100, Scott Wilson > wrote:



Hi both,

Apache Wookie (incubating) currently implements the widget.openURL
method by directly calling the browser's window.open() function - in
this example is there anything particularly special about the fact  
its
being called by a widget? Should our implementation do anything  
extra,
or is it better just leaving it to the browser to handle any  
problems?


The way I view this is roughly as follows:

1. window.open() opens a URL within the context of the widget, for  
instance for the purpose of authenticating a widget using something  
like oAuth.


2. widget.openURL() is used to pass a URL from a widget to the  
default protocol handler on a system for any given protocol, for  
instance to pass a URL from the widget to the web browser on the  
system, to place a phone call or pass a magnet link to a bittorrent  
client


The underlying difference here is that window.open would retain a  
reference to the widget, usually through window.opener, while  
widget.openURL is fire and forget.


Thanks, Arve, that's useful.

I guess in that case we should remove the reference to the widget's  
window from the new window, e.g.:


widget.openURL = function(url){
remote = window.open(url);
remote.opener = null;
}


--
Arve Bersvendsen

Opera Software ASA, http://www.opera.com/




smime.p7s
Description: S/MIME cryptographic signature

Re: [widgets] API - openURL security considerations

[Scott Wilson]

Hi both,

Apache Wookie (incubating) currently implements the widget.openURL  
method by directly calling the browser's window.open() function - in  
this example is there anything particularly special about the fact its  
being called by a widget? Should our implementation do anything extra,  
or is it better just leaving it to the browser to handle any problems?


S

On 18 Feb 2010, at 09:50, Thomas Roessler wrote:


Marcos,

first of all, kudos for thinking about security considerations for  
this method.  I'm glad you're considering factors like interaction  
flooding and tons of windows opening.


Reviewing the spec text:
http://www.w3.org/TR/2009/CR-widgets-apis-20091222/#the-openurl-method

... I wonder whether the specification actually says that openURL  
will ever return upon success.  You say that the widget's browsing  
context must not be navigated ("for security reasons" -- which  
ones?  Access to special features within the widget context?)  --  
but do you forbid simply destroying the widget (or never returning)  
when openURL is invoked?


If the method never returns, then the attack you're concerned about  
is probably infeasible (which would be good news); it would also tie  
widgets into a very specific application model that I don't know is  
desirable.  You probably want to clarify this.


So, to the security considerations:

- if openURL can be executed multiple times, then pretty much  
everything one can say about pop-ups applies

- as Adam said, file: URIs deserve some extra thought
- it's perhaps worthwhile to spell out to implementers that there  
are many ways to write a URI handler that isn't safe, e.g., assuming  
that just because a scheme has a particular syntax that syntax is  
actually followed.


Regards,
--
Thomas Roessler, W3C  







On 8 Feb 2010, at 17:36, Marcos Caceres wrote:

At Opera we've been discussing some of the security implications  
around the openURL method in the widgets API spec. We think the  
spec might benefit if we were to add a non-normative security  
consideration section for openURL.


We are basically concerned about protecting against a simple attack  
such as:


while(true){
openURL("http://...";);
}

The following text, which I did not write, can serve as a basis for  
the note - we are presenting it here for discussion, and you'll  
note it uses different terminology than the one found in the spec.  
In other words, please don't consider the following to be spec  
text, it needs a fair amount of editing but tries to get to the  
heart of the problem:


[[
APIs to open external programs, such as opening a URL in a browser,  
SHOULD only be allowed automatically if the widget has focus.  
Opening such an external program, SHOULD result in the widget  
losing focus, for the purpose of opening more external programs.  
User interaction with the widget may restore the focus to the  
widget. Widget Managers MAY offer a dialog for other attempts to  
open external programs, or MAY fail the operation. User agents MAY  
also offer an override for users to allow a widget to open external  
programs automatically, even when minimized in the background.


Security considerations: Widgets may have managed run-time  
constraints, for instance on memory usage or domain access, and  
opening multiple instances of external programs may easily exceed  
those constraints. External programs may present dialogs to perform  
harmful actions, e.g. download dialogs, and multiple new windows in  
a short time span may allow for interaction flooding attacks or may  
lead to warning fatigue. This security measure ensures that users  
get a reasonable chance to manage the run-time constraints, and  
ensures that only one external program and/or dialog can be opened  
at a time.

See http://www.w3.org/TR/wsc-ui/#popups for more details.
]]

We would appreciate any feedback people have about the proposed text.










smime.p7s
Description: S/MIME cryptographic signature

Re: Social APIs (was: Rechartering WebApp WG)

[Scott Wilson]

On 17 Feb 2010, at 00:19, Harry Halpin wrote:


On 17 Feb 2010, at 00:19, Harry Halpin wrote:

Yes, we over in the Social Web XG would be happy to provide some space
where efforts like this one can be done, in particular a "Social API
requirements" telecon and e-mail discussion with WebApps would be
great. Looking at the list made earlier:

"* access to contacts on a specific device: Contacts API (DAP WG) [4]"

This is obvious an important point, but we need to make sure that
Contacts API is compatible with PortableContacts/vCard, and maybe even
look at FOAF.


Or simply that there is a reasonable abstraction over different  
approaches to handling contacts at the app/widget level


E.g. Wave Gadgets has an extremely simplified user info model: id,  
display_name, thumbnail_src that would map easily onto any of the  
contact schemes discussed (and is surprisingly useful). By contrast,  
OpenSocial has a maximal scheme that encompasses all manner of bizarre  
attributes (SCARED_OF, HAPPIEST_WHEN etc), presumably the superset of  
everything the initial OS members stored about people!



" * access to relationships between contacts, etc.: no current work,
but  possible as an online service (XHR), or locally through markup
like RDFa or microdata" - I think this could be covered by some new
API.

Agreed, and we could also make sure that those in RDF have a
declarative metadata approach that is compatible with some new API,
but that users of such a API would not have to know about or use, i.e.
compatible but orthogonal.


+1


Personally, I believe that if the relevant stake-holders can be
brought on board, this would be a very worthy area for future
standardization and will do everything I can to help. Looking at our
schedule, we were hoping to have a call on this topic (i.e. W3C
Widgets and OpenSocial), March 10th (5 PM GMT) still works [1].


Yes, the 10th is still good for me too.

Would you like me to ask the Apache Shindig developers if any of them  
can join us?



For a general update on our work, take a look at our minutes [2] and
wiki [3]. We'll have a draft final report out by end of March, but
expect the XG to be extended by 3-6 months as we are still in the
middle of a number of conversations.

 -harry

[1]http://www.w3.org/2005/Incubator/socialweb/wiki/Schedule
[2]http://www.w3.org/2005/Incubator/socialweb/
[3]http://www.w3.org/2005/Incubator/socialweb/wiki/


smime.p7s
Description: S/MIME cryptographic signature

Re: Social APIs (was: Rechartering WebApp WG)

[Scott Wilson]

On 13 Feb 2010, at 20:52, Doug Schepers wrote:


Hi, Scott-

This is certainly a valid aspect of Widgets... as a platform for a  
specific kind of Web application: a collaboration/discussion/sharing  
app.


But it seems to me that this is conflating two orthogonal things: an  
application host environment, and a collaboration platform.  Widgets  
can host the full range of Web apps; and a collaboration platform  
shouldn't be confined to Widgets.


The context for a Widget, in my opinion, shouldn't inherently  
contain the users of that Widget; that is functionality that should  
be specific to collaboration apps.


As an analogy, think of the Geolocation API.  A recipe widget which  
finds recipes based on a list of available ingredients has no use  
for that API, but a shopping widget might; traditional web sites  
built to do those things would have the same needs.  So, the  
Geolocation API is much better off as a standalone API that is  
available when needed, and not imposed when not needed, as general  
functionality, not just for Widgets.


Agreed. A Widget is only one possible consumer of such an API, so it  
make sense to define the API separately (with Widgets as one type of  
use case).


It also seems that it would require more than just an API... it  
needs an infrastructure from which to draw the relationship data,  
and security considerations.  Like the Geolocation API encapsulates  
underlying device/service functionality (GPS, cell/wifi  
triangulation, logged IP locations, etc.), and the Widget  
Interface's Storage API uses functionality defined elsewhere  
(LocalStorage, SessionStorage, IndexedDB, WebDB, remote web  
service), a Social API would have to rely upon some source of data,  
which is not inherent in the device or a single established web  
service, so that would need to be defined.


Indeed, both collaborative and social apps require the container to  
have a means of access to a data source, and are also responsible for  
applying appropriate access and privacy policies; a parallel here  
would be DAP (and OMTP BONDI).


I don't think the WebApps WG is the right place to work on a Social  
API; I don't think it would get the specific interest such an API  
would require to do it right, with the current participants of this  
group (though others in the group should correct me if I'm wrong).   
Also, the WebApps WG has an urgent need to renew its charter to  
bring in deliverables we've already agreed are in scope, so I would  
be extremely reluctant to bring in a deliverable at this stage that  
has as broad a scope as a Social API.


That's not to say a Social API is not useful or desirable.  I'd love  
to see this done at W3C, and I think it's important to make sure it  
works well in both web sites and widgets.  So, my counterproposal is  
to suggest that you work with Harry Halpin to propose a new Social  
API WG (maybe under Interaction Domain, but more fittingly under the  
Technology and Society Domain), and bring in the Google Wave and  
Open Social folks (since Google is already a W3C member), and find  
other stakeholders (Facebook?) who might also be interested, to help  
standardize what they have all already done.  Harry and I have  
talked a bit before about next steps for the Social Web, and this  
strikes me as a logical and pragmatic next step.  I will be happy to  
do what I can to help set this up, and to ensure good communication  
between our groups, and to make sure that it works well with Widgets.


I think this is a very good proposal; I'm happy to drop the proposal  
for doing this in Webapps and work instead with the Social Web group  
as you suggest.




Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Scott Wilson wrote (on 2/13/10 5:21 AM):

Hi Doug,

I'm not adamant that these requirements are met specifically just for
Widgets, just that these are where the current use-cases come from.  
They
certainly ought to be supported through more general technologies  
where

possible.

There is also the issue of abstraction; should a widget author be
looking at low-level APIs to deliver functionality, or call a common
high-level API which is then implemented in a
device/architecture-specific way? E.g. if a widget author script  
wants
to get the list of current participants, should it need to be  
rewritten

for every platform it might be deployed in (e.g. XHR in some, Web
Sockets in another, native code another...) or can it call
"widget.getParticipants()" and let the UA handle the implementation?

Just as, for example, the Widget Interface defines "preferences"  
using

the Storage API: the actual choice of implementation of this
(LocalStorage, SessionStorage, IndexedDB, WebDB, remote web  
service) is

up to the UA.

So what I'm talking about here, just to be clear, are the high  
level API
abstractions available to a running widget (and p