Re: [widgets] Timeless' Widgets Requirements LC

Hi Josh,
I've addressed all comments below. For the sake of the disposition of
comments, please acknowledge that you are happy with the corrections
and that I've addressed everything you wanted addressed.

On Thu, Aug 21, 2008 at 8:46 AM, timeless <timeless@gmail.com> wrote:
>
>> 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.

Yes. That is the intent (sort of)... though not relating to the
functionality your are describing. It's just so a file name like
"signature.xml" is reserved and has special meaning.

>> 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:).
>

Agreed. This is a spec issue. However, I think the Requirement is
clear enough.

> 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....
>

Again, a spec issue.

>>>>> 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.

Your proposed text above is now in the spec.

>> 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.
>
Ok, it now reads "For example, in the context of a widget gallery
website, a server may automatically extract the configuration document
from a widget resource and serve it upon request. "

>> 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....

As above.

>> 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 ;-).
>

Ok.

>>>  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).

Fixed. Now uses WebIDL

>> "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 :)
>

Great.

>>> 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.
>
>



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

Received on Friday, 5 September 2008 14:02:44 UTC