W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [widgets] Timeless' Widgets Requirements LC

From: timeless <timeless@gmail.com>
Date: Thu, 21 Aug 2008 10:46:22 +0300
Message-ID: <26b395e60808210046u1c6e9186h274c730fec84877d@mail.gmail.com>
To: "Web Applications Working Group WG" <public-webapps@w3.org>

> COMMENT: Although logically true, I think the intention of the text is
> clear enough.

ok

>> A conforming specification must indicate if any resources
>> are mandatory or reserved and what specific function they serve
>> in the widget resource.
>> Rationale:
>>   To make it more efficient for widget user agents to locate the resources
>> they require at runtime. For example, the packaging format may require
>> authors to place all resources inside a 'resources' directory located at the
>> root of the widget resource.
>> 1:25 PM i don't understand how that justifies the previous bit
>>   to address the individual
>
> QUESTION: unsure how to proceed. Can you please reiterate your concerns.

i think the problem is that i couldn't understand how/why the rational
related to the requirement.

if you mean something like:
  For example, the packaging format may require
  authors to place all images inside a 'resources' directory located at the
  root of the widget package to enable widget user agents to precache
  images.

> resolves to something akin to "widget://myWidget/images/bg.png"))."
>
> QUESTION: does the new example make any more sense?

it's slightly better, but i think the scenario should be more like

your file is something_localized/file.html and you're trying to reach
something_maybe_localized/images/bg.png

so you use "/images/bg.png" where / is rooted to the package protocol
(e.g. widget:).

or perhaps a better thing is you have code which wants to use
window.location to dynamically construct ./images/bg.png and in order
for this to work, window.location must work....

>>>> To allow the configuration document to be extracted and used by other applications (either on the server or on the client side) for different purposes.

>> 4:10 PM the parenthetical bothers me. i might have a widget aggregator which

> QUESTION: unsure how to proceed here? The requirement is simply that
> other software programs can get at the configuration document and use
> it as they please.

To allow the configuration document to be extracted by unrelated
programs (not necessarily client or server side) and used by other
purposes.

> COMMENT: Agreed. I think the Working Group were thinking about this
> more from a developer or distributor's perspective. A distributor
> could set up a Web service that serves the widgets' configuration
> documents available on his or her widget repository. The developer
> could then build a widget that allows the repository to be browsed,
> etc.

i think offering the example of a distributor gallery could be
included in rationale.

> COMMENT/QUESTION: I think I'll leave the comment for now, but if the
> issue comes up again I will change it to be more clear. However, if
> you *really* think it should be changed, I will change it.

i keep reaching the same conclusion as i rewrite/reread....

> COMMENT: Retaining "preferences" as this is the matches the language
> we use in the API spec.

oh well

> COMMENT: Agreed, however, how vendors deal with UI issues is an
> implementation detail. I think the requirement is probably clear
> enough.

ok

> COMMENT: yep, it's certainly annoying but I think it again captures
> the intention.

> COMMENT: agreed. However, I still think the current example is good enough.

we'll see how much drain these devices get. i've definitely seen
groups who think flashing is a good thing, and i've recently worked
with groups who complain that people should know that flashing is a
bad thing.

i keep reaching the same conclusion. Now I can also point to App Store
which uses the same red circle indicator, if you want to suggest a
star instead, that's fine ;-).

>>  timeless.bmo1: A conforming specification must specify the APIs proposed in
>> this section in such a way that they are implementable in ECMAScript.

> COMMENT: I think the intention of this statement is fairly clear. If
> you want to suggest some better text I would be happy to include it.

> QUESTION: Can you suggest some better text for R31. ECMAScript Compatibility?

the language still doesn't work... i guess just reference WebIDL
(actually I discussed this w/ marcos and that was really his idea).

> "unparring")."
> QUESTION: does that sound ok?

it seems in my later full read that i indicated the last word in the
block was not ok, "oops" :)

but yes, otherwise, it sounds fine :)

>> 4:59 PM perhaps you should have a define at the top that says "HTTP" in this
>> document means HTTP or HTTPS
> COMMENT: addressed by citation.

ok

> COMMENT: Keeping preferences for now.

oh well

> COMMENT: agree, not the best example, but it gets the point across I think.

ok

> COMMENT: I think it is generally assumed within the working group that
> a user is at least one of the things or people you listed above.

ok.
Received on Thursday, 21 August 2008 07:47:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:27 GMT