Below is a review that Josh Soref (Timeless) did of the Widgets
Requirements LC. The review was conducted using gMail's chat
yesterday. I've marked where I've made editorial changes.
Josh raised two significant issue which requires discussion from the WG:
ISSUE 1: should we mandate that developers and admins be allowed to
install their own certs? (R38. Additional Digital Certificates)
ISSUE 2: Widgets (not just widget engines) should be able to specify
which proxies they communicate through.
Josh, I've responded by marking sections as:
TYPO: fixed a typo. You can ignore all these.
EDITORIAL: made an editorial change as you suggested.
Please indicate if you _not_ satisfied with any of these.
COMMENT: either a disagreement with suggested change or an
explanation of why a something was addressed in
some particular way
QUESTION: anything I was unable to understand or
need further guidance on.
On Wed, Jun 25, 2008 at 12:44 PM, timeless.bmo1@gmail.com
<timeless.bmo1@gmail.com> wrote:
> 12:49 PM me: http://dev.w3.org/2006/waf/widgets-reqs/
> timeless.bmo1: Widgets are ... for displaying and updating remote data
> i can't have a widget that's a clock?
> 12:55 PM anyway, the next sentence contradicts the line i quoted
> Typical examples of widgets include clocks
> me: Re: clock widget, would "widgets are ... for displaying and/or updating
> remote data" ? or just "widgets are ... for displaying or updating remote
> data"
> 12:56 PM timeless.bmo1: neither help
> since a clock has 0 remote data
> Typical examples of widgets include ..., games, and those that make use of
> Web services
> "those" doesn't backreference properly
> 12:57 PM me: hmmm...
> "and widgets that" ?
> 12:58 PM "and widgets that make use of Web services, ..." can work
> timeless.bmo1: seems ok
EDITORIAL: changed "those" --> widgets
> A widget is an interactive single purpose application
> clocks may not be interactive
> note that the introduction sentence is better than the earlier one
> 12:59 PM might want to sync them :)
> A widget may run as a stand alone
> stand-alone ?
TYPO: Fixed.
> timeless.bmo1: the runtime environment on which
> in which
TYPO: Fixed.
> timeless.bmo1: As argued by the Widget Landscape
> argued? scary
> 1:01 PM there is currently no formally standardized way to author, package,
> digitally sign and internationalize a widget resource for distribution and
> deployment on the Web
> me: Well, we don't have definitive proof.
> so "argued" seemed like the right word
> timeless.bmo1: i think you want 'or' instead of 'and' before
> internationalize
> but i'm not certain
TYPO: and --> or
> 1:04 PM is as interoperable as possible with existing market-leading user
> agents (known also as widget engines) and existing Web browsers.
> are market-following user agents not known as widget engines?
>
> timeless.bmo1: note that "known also as" is poor, it's better to write
> "also known as"
EDITORIAL: removed "(known also as widget engines)"
> 1:05 PM To be clear, this specification describes the requirements for
> installable/desktop-style widgets (akin to Dashboard, Opera Widgets, and
> Yahoo!'s Konfabulator Widgets). This document does not address the
> requirements of "web widgets", such as iGoogle Gadgets or Windows Live
> Gadgets.
> i'm not sure that helped me at all
>
> timeless.bmo1: i don't suppose you could footnote links to references or
> examples of those features?
EDITORIAL: Added hyperlinks to information about each product.
> timeless.bmo1: should not,recommended
> space after comma, please :)
TYPO: fixed.
> 1:07 PM timeless.bmo1: Note, however, that not all requirements may be
> addressed by those specifications, particularly requirements marked with the
> key word may.
> negatives, all, precedence => mess
> timeless.bmo1: you may want to use 'some' instead of 'all', or just rewrite
> the whole thing
EDITORIAL: section rewritten as "Note: Only normative statements
marked with the keywords MUST and should are required to be
standardized by the Widgets 1.0 family of specifications."
> 1:08 PM A conforming specification is one that addresses all the
> requirements (particularly those that contain the words "must" or "must
> not") listed in this document.
> if you're generating 5 specifications
> and none of them satisfy all of the requirements, but taken together they
> do
> then you have 5 non conforming specifications according to that
> even though the real goal is accomplished :)
COMMENT: Although logically true, I think the intention of the text is
clear enough.
> timeless.bmo1: i think things that aren't addressed need to be highlighted
> with a reference as to why they're being ignored
> 1:10 PM me: I think they should probably just be removed from the final doc
> 1:11 PM timeless.bmo1: it's probably ok for them to be absent from the
> document, but there should probably be a clear and easily findable
> explanation for why something isn't there
> 1:12 PM we get all sorts of strange requests on irc.mozilla.org
> "why can't i do X"
> yes it's true we explain how A-W work
> but sometimes it'd help if we explain why X just isn't there
> me: I see what you mean
> 1:13 PM a compendium document "Informative Notes about unaddressed
> recommendations" would probably work
> that enables it not to be part of the primary deliverable but leaves it
> easily linkable etc
EDITORIAL: Added the text "The Working Group will publish an
informative Working Group Note at the end of the standardization
process listing any requirements that were not formally addressed by
the Widgets 1.0 family of specifications."
> timeless.bmo1: doesn't look like things are required to be easy to
> implement
> 1:15 PM (and yes, i know the group probably has more active implementers
> than it has active consumers, but still)
> A conforming specification needs to support relevant internationalization
> and localization guidelines, as well as consider current practical
> internationalization solutions used by the widget development community.
> this doesn't seem to indicate that it has to enable internationalization
> 1:16 PM i read it as saying that language letter codes could be imported
> from a guideline
> but the spec could choose not to support localization
EDITORIAL: Changed
"A conforming specification needs to support relevant
internationalization and localization guidelines"
-->
"A conforming specification needs to implement relevant
internationalization and localization guidelines"
COMMENT: The widget packaging spec already implements aspects of BP47
for i18n and attempts to conform to XML i18n best practices
[http://www.w3.org/TR/xml-i18n-bp/]. The i18n core WG has been
assisting us with this.
> 1:17 PM A conforming specification needs to be specified in such a way that
> it ensures that a widget resource can still be processed well into the
> future (e.g. 100 years from date of the a specification reaching
> "Recommendation Status" W3C Process).
> 100 years is nice. is that a standard thing?
> because in practice, none of my phones will last that long
> timeless.bmo1: and all of the browsers will have obsoleted everything
> timeless.bmo1: A conforming specification needs to address the security
> concerns of end-users and vendors by recommending appropriate security
> policies and programming behavior. A conforming specification must also
> consider the distribution and deployment security requirements as they
> relate to authors and vendors.
> vendors to me here are user agent authors and not web application hosts,
> and certainly not random devices on the internet. we need to protect all of
> them
EDITORIAL: The section now reads "A conforming specification needs to
address the security concerns of end-users, authors, distributors and
device manufacturers by recommending appropriate security policies and
programming behavior."
> 1:19 PM 4. Requirements
> doesn't say 'normative' or 'informative' unlike the previous n sections
EDITORIAL: added "This section is normative."
> 1:20 PM R2. File Extension
> 1:21 PM doesn't seem to say that a requirement should attempt to register a
> mime type
> (yes, it's almost implied, but..)
EDITORIAL: I've moved Requirement 12 "MIME Type" and made it
Requirement 2. This way, the reader won't wonder about how the MIME
type relates to the file extension.
> 1:22 PM "Note also that"
> i'm not a fan of that.. I'd normally write "Also note" or something...
> Note also ... Web servers may also
> ETOOMANYALSOS
EDITORIAL: text was rewritten: "Also note, in some cases, Web servers
may rely on a file extension to correctly set a widget resource's MIME
type in the HTTP headers."
> 1:23 PM A conforming specification must specify graceful error
> handling/recovery procedures if those resources are used erroneously or are
> missing.
> 1:24 PM some of the error handling you've specified in the other document
> isn't graceful, it's forceful hard failure.
COMMENT: True. I've relaxed this to a 'should': "...specification
SHOULD specify graceful error..."
> 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.
> drop 'the'
TYPO: deleted "the".
> 1:26 PM or are already accustomed to.
> ends in a preposition. "to which they are already accustomed" is proper
> English.
EDITORIAL: text now reads: "The addressing scheme should be one that
web authors would feel comfortable using or to which they are already
accustomed."
> 1:27 PM addressing a resource via an IRI (e.g. new
> Image('../images/pane.png')).
> i don't think your example helps
> you don't need a special protocol to enable relative paths to work
EDITORIAL: Rewrote Rationale "To allow resources to be resolved and
normalized within DOM attributes. To make it easy for authors to
address and load resources into their instantiated widgets, either
declaratively or programmatically. For example, addressing a resource
via an IRI (e.g. <img src="images/bg.png'/> where the src attribute
resolves to something akin to "widget://myWidget/images/bg.png"))."
QUESTION: does the new example make any more sense?
> 1:29 PM complete with error handling, the reduces
> "the reduces" is wrong here. the natural fix is "this reduces" but i think
> you want to rewrite the sentence to use "to reduce"
EDITORIAL: sentence now uses "to reduce"
> 1:30 PM A conforming specification must recommend a packaging format that is
> suitable for delivery onto many devices, particularly Web-enabled mobile
> devices.
> delivery to
TYPO: onto --> to
> 1:46 PM timeless.bmo1: including it's title
> /its/
TYPO: fixed.
> 1:48 PM that represent metadata about the widget
> probably a widget
TYPO: the --> a.
> reusable in other contexts (for instance, to create an online gallery
> 1:49 PM i'd write showcase. galleries are assumed to be image galleries
COMMENT: Although I agree, I'm keeping gallery as extracting the
<thumbnail> element from widgets can be used for creating an image
gallery.
> 3:47 PM timeless.bmo1: However it may be able to address a resource on the
> Web over HTTP but only of the MIME types allowed by the automated bootstrap
> requirement (below) or resources that are of media types supported by a
> widget user agent.
> 3:48 PM , after However; what about HTTPS?
TYPO: added ",".
EDITORIAL: I've added "HTTP Over TLS. E. Rescorla. May 2000.
http://www.ietf.org/rfc/rfc2818.txt" as a <dd> of [HTTP] in the
references section.
> declared by an author, then automated bootstrapping must occur as describe
> described
TYPO: fixed.
> 3:49 PM (eg '/ui/clock.svg').
> "e.g.,"
TYPO: fixed.
> 3:51 PM The widget user agent should be allowed to select its preferred
> format for the start file, then it should
> file, and then ...
> (index.htm, index.html, index.svg, etc)
> etc.
TYPO: fixed.
> 3:52 PM firstly within localized directory names, as required by automatic
> localization, within the directories of the widget resource.
> automatic localization, and then within
TYPO: added "and then".
> starting form the root directory.
> 3:53 PM "from"
TYPO: fixed.
> 3:54 PM The conforming specification should not ... SHOULD provide
> alternative text representations of an icon where possible
> should "should not" be uppercase?
TYPO: fixed.
> timeless.bmo1: the SHOULD part is wrong
> it should provide for support for
> not should provide
TYPO: added "it"
> timeless.bmo1: To provide authors with a visual means of representing
> widget
> widget_s_
TYPO: fixed.
> For example, an a small graphic
> /as/ a small ?
> hrm, no
> 3:57 PM For example, an a small graphic of a calendar may represent a
> calendar widget.
> For example, -- a small graphic of a calendar may represent a calendar
> widget.
> just remove 'an'
TYPO: fixed.
> A conforming specification must specify a means to declare values of
> either custom or predefined configuration parameters,
> 3:58 PM 'or' doesn't mean what you want
> timeless.bmo1: it basically means the spec could specify A. the spec could
> specify B. the spec does not have to specify A and B
> you want 'and' :)
> 3:59 PM which would be applied as a widget is instantiated.
TYPO: fixed.
> timeless.bmo1: instead of 'a widget' probably want 'each widget', however i
> think you need 'all of which'
> otherwise you're only saying that 1 value might be....
EDITORIAL: added "all of which"
> 4:00 PM A conforming specification must specify the default values for
> parameters in case a parameter is missing or the value supplied by the
> author is invalid.
> needs to be limited to spec defined parameters
> defining default values for author fields doesn't make sense :)
EDITORIAL: Changed it to "A conforming specification MUST specify the
default values for specification defined parameters in case a
parameter is missing or the value supplied by the author is invalid."
> timeless.bmo1: the author might declare that the value for the parameter
> 'width = "50"', or in its absence, the widget user agent will automatically
> set the width to "300".
> i think you've over quoted width = "50", i.e. lose the single quotes
> 4:02 PM it's possible you really want it fully quoted
> in which case the sentence needs a rework
> me: given that it's just an example, it's probably ok to drop the "50" and
> just have width = 50
> 4:03 PM timeless.bmo1: the author might declare '...' indicating the 50 as
> the value for width, or in its ...
EDITORIAL: changed text to "<code>width = 50</code> indicating the
<code>50</code> as the value for width"
> timeless.bmo1: To declare the security intentions of the widget, allowing
> the widget user agent to respond accordingly by adjusting its security
> policies and warning the end-user.
> "respond" is problematic
> it's a static proposal
> 4:05 PM me: allowing the widget user agent to adjust its security
> policies... ?
> 4:06 PM timeless.bmo1: allowing WUA to e.g., confirm with the user before
> installing the W, or adjust its policies before instantiating it.
EDITORIAL: Rewrote to "To declare the security intentions of the
widget, allowing the widget user agent to, for example, confirm with
the user before installing the widget, or adjust its policies before
instantiating it."
> R22. XML, Micro-Syntaxes and Schema
> is the 's' in syntaxes supposed to be in uppoercase?
> timeless.bmo1: lose the shift ;-)
TYPO: fixed.
> 4:08 PM timeless.bmo1: and XML parsers generally have reasonable support for
> Unicode and other character encodings
> other ??
EDITORIAL: dropped "and other character encodings".
> 4:09 PM 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.
> different => unrelated
EDITORIAL: changed different => unrelated
> 4:10 PM the parenthetical bothers me. i might have a widget aggregator which
> parses things. e.g. http://www.gronmayer.com/it/
> gronmayer is neither a dpkg-ua, nor a dpkg-server
> 4:11 PM well, as long as we define dpkg-ua as something that runs on the end
> user's device ... it presumably uses dpkg, but it doesn't have to. e.g.
> timeless.justdave.net/mxr-test/chinook barely uses dpkg and doesn't need to
> (it could bypass it entirely and i'm fairly tempted at times).
> 4:12 PM The independent configuration document may then be used, for
> instance, for checking information about the widget without needing to
> download the complete widget resource.
> timeless.bmo1: the example is bad. since the file is naturally only
> available in the archive which would require downloading it
> one requirement is that you don't have to parse all files in the entire
> archive
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.
> 4:13 PM and the other is so that you could cache and store just this file
> for use, w/o retaining the whole archive
> (neither gronmayer nor my server retain the originals)
> hrm. ok, the problem isn't quite what i described
> it's that the English text didn't work :)
> 4:14 PM "The independent" didn't backreference correctly
> change it to "The extracted"
EDITORIAL: changed independent -> extracted
> 4:15 PM timeless.bmo1: but it's still problematic, since widget uas have no
> reason to manually read the file outside an archive
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.
> you really would almost need to have some way to tell a wua that it needs
> to be able to read a standalone configuration file to a user
> and that gets messy
> timeless.bmo1: i think you're better off changing the example to that of an
> aggregator
> or marketplace
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.
> timeless.bmo1: to standardize a API for widgets
> an API :)
> specifies an API that allows
> like that :)
TYPO: fixed.
> timeless.bmo1: # Safely access services, resources, and other applications
> on a user's device.
> on the user's device
TYPO: fixed.
> 4:18 PM These interfaces must be encapsulated as a self-contained object or
> some similar data structure in a non-object-oriented programming
> environment.
> i need to check my English, i kinda want a comma before 'or'. the sentence
> is too heavy and doesn't balance the way i want...
TYPO: added coma.
> 4:19 PM A conforming specification must specify a set of interfaces that
> expose the properties, methods, and events of an instantiated widget.
> the word the in this sentence is annoying me
> i'm fairly certain you should omit it
> 4:20 PM as written i could have something which has no properties/methods or
> events
> and that'd enable me to easily expose all (zero) of them
> w/ the _the_, you're asking me to actually do work :)
TYPO: removed "the"
> timeless.bmo1: availability of network access, etc. See
> etc.. <- note the second period
> again, etc. is an abbreviation, and needs its own dot, but that dot isn't
> really a period to end a sentence.
TYPO: added "."
> 4:22 PM A conforming specification must specify a set of interfaces for
> dynamically getting and setting preferences that are unique for an
> instantiated widget.
> 4:23 PM ... preferences _for the widget instance_.
EDITORIAL: changed to "A conforming specification MUST specify a set
of interfaces for dynamically getting and setting preferences for the
widget instance."
> To provide a means for authors to allow end-users to dynamically change
> any preferences they may have set in the past.
> preferences => settings
COMMENT: Retaining "preferences" as this is the matches the language
we use in the API spec.
> 4:24 PM actually, the section header should be something like Storage of
> instance specific data
EDITORIAL: R26. renamed to "Storage of Instance Specific Preferences"
> 4:25 PM timeless.bmo1: A conforming specification must define a set of
> states in the lifecycle of the instantiated widget that are able to be
> captured through script.
> 4:26 PM i don't understand
> To allow authors to programmatically capture when a change has occurred in
> either the instantiated widget or possibly even the widget user agent.
EDITORIAL: simplified the text to "To allow authors to capture
state-change events generated by the instantiated widget."
> 4:27 PM timeless.bmo1: The specification MUST NOT require the WUA to send
> events to the widget immediately, and SHOULD allow the WUA to dispatch them
> at its convenience (e.g., because it doesn't want the widget to do work now
> because it's running low on power)
EDITORIAL: It now reads: "A conforming specification MUST define a set
of states in the lifecycle of the instantiated widget that are able to
be captured through script. A conforming specification MUST NOT
require the widget user agent to send events to the widget
immediately, and should allow the widget user agent to dispatch them
at its convenience."
> R28. Network State Change Events
> 4:28 PM the specification MUST NOT guarantee event delivery, as there may be
> cases where a device is running low on power and can not afford to deliver
> them.
EDITORIAL: Text now reads "A conforming specification MUST specify a
means that allows authors to check if the widget resource is connected
to the network. A conforming specification MUST define the scope of
the term "network" and MUST specify a means by which connection and
disconnection events can be captured by an author through script. A
conforming specification MUST NOT guarantee event delivery, as there
may be cases where a device is running low on power and can not afford
to deliver them."
> 4:29 PM how an instantiated widget (or any of its windows) should to
> categorize itself
> "should to categorize" is wrong/bad. probably just drop 'to', although
> 'categorize' is an annoying word
TYPO: dropped "to"
EDITORIAL: categorize --> classify
> more instances of 'etc.' w/ too few periods. i'm not going to flag
> anymore, but they all need to be correct :)
> 4:30 PM Some of these mode changes may require the end-user's attention, in
> which case the widget user agent should find a suitable and non-intrusive
> way to draw the end-user's attention.
> that's kinda self defeating
> perhaps, should provide a way for the user to find out that attention is
> required
EDITORIAL: dropped "and non-intrusive" and modified sentence. It now
reads: "Some of these mode changes may require the end-user's
attention, in which a case conforming specification SHOULD recommend
that widget user agent find a suitable way to draw the end-user's
attention."
> 4:31 PM asking the WUA to somehow draw the user's attn. is invasive.
COMMENT: Agreed, however, how vendors deal with UI issues is an
implementation detail. I think the requirement is probably clear
enough.
> An example of this kind of behavior can be seen on Mac OS X, where a
> program's icon bounces in the dock when a program has a critical window to
> display.
> a Bad example
COMMENT: yep, it's certainly annoying but I think it again captures
the intention.
> 4:32 PM fair enough
> timeless.bmo1: a better example is the iPod touch's mail app which changes
> the widget to include a new mail number in a corner
> no flashing.. really, no flashing
COMMENT: agreed. However, I still think the current example is good enough.
> 4:33 PM but should provide some means of binding to those APIs if they are
> available.
> ... and the user agrees
> SHOULD NOT do so without consulting the user or a policy which exists to
> represent the user.
EDITORIAL: the requirement now reads "A conforming specification
SHOULD specify a mechanism, either through an API or through the
configuration document, which allows instantiated widgets to bind to
third-party APIs that allow access to device-specific resources and
services. A conforming specification is not required to specify any
APIs to device specific resources or services, but SHOULD provide some
means of binding to those APIs if they are available and the user
agrees. A conforming specification SHOULD specify that bindings MUST
NOT occur without consulting the user or a policy which exists to
represent the user."
> 4:34 PM include cameras, SMS, GPS and address book.
> cameras is plural, SMS and GPS are ambiguously plural
> parallelism says address books should be plural
TYPO: fixed.
> timeless.bmo1: A conforming specification must specify the APIs proposed in
> this section in such a way that they are implementable in ECMAScript.
> "are implementable" doesn't include a reasonableness bit
> 4:36 PM (again, i know we have lots of people representing them, but still,
> let's be clear that it's a requirement)
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.
> To support a language that is already widely used in widget user agents
> and to allow authors to use already existing ECMAScript code libraries.
> 4:37 PM not sure if you mean implementable. if you do, then you don't mean
> authors. because authors by default is widget authors
> whereas if you mean implementable, then you're talking about a different
> group of people
> otoh, you might mean usable
> or you might mean both, in which case you need more sentences :)
QUESTION: Can you suggest some better text for R31. ECMAScript Compatibility?
> 4:39 PM To allow widget to communicate with each other.
> widget s
TYPO: fixed.
> timeless.bmo1: a stock widget stock quotes widget
> the the is usually a spelling error :)
TYPO: fixed.
> timeless.bmo1: the spec SHOULD provide a way for users to be aware of
> widget dependencies and to introduce widgets to each other ("pairing").
> as well as unpairing.
> 4:41 PM if i have a news ticker and a stock ticker, i don't want them
> automatically finding eachother
EDITORIAL: Changed the text of R33. Cross-Widget Communication, to "A
conforming specification MAY specify a model and API to allow multiple
instantiated widgets to securely communicate with each other. A
conforming specification attempting to address cross-widget
communication SHOULD provide a way for users to be aware of widget
dependencies and to introduce widgets to each other ("pairing" and
"unparring")."
QUESTION: does that sound ok?
> 4:42 PM To allow authors to easily access metadata they declared in the
> configuration document at runtime.
> "at runtime" bound wrong
> you need to move it earlier in the sentence
> as written it sounds like the widget created the configuration document at
> runtime :)
EDITORIAL: changed sentence to "To allow authors at runtime to easily
access metadata declared in the configuration document. "
> timeless.bmo1: A conforming specification SHOULD specify a means that
> allows authors to open URLs in a browsing contexts outside the widget
> engine.
> 4:43 PM in a browsing context s ... no bad :) lose one or the other
TYPO: "s" is gone
> timeless.bmo1: The objective of this section is to ensure that a conforming
> specification mandates a language that is well-suited for creating user
> interfaces and is accessible.
> 4:44 PM accessible bound to the language, not the user interfaces :(
> which i would have thought wasn't what you wanted, since i couldn't
> imagine any reason to want an accessible language
> 4:46 PM timeless.bmo1: what you want to be accessible is what's described by
> the language
> not the language itself
> timeless.bmo1: your English document isn't accessible
> and that's risking making the next document also not accessible, which in
> turn could make the final widgets not accessible, while still resulting in
> an accessible product (html documents)
EDITORIAL: new text "The objective of this section is to ensure that a
conforming specification mandates an accessible language that is
well-suited for creating user interfaces."
> 4:47 PM (and yes, that English was awkward, i should have used inaccessible)
> through an non-graphical UI
> an => a
TYPO: fixed
> 4:48 PM The declared interface may also be accessible to screen readers,
> allowing relevant sections of text and functionality to be accessed by
> non-visual means
> MAY implies MAY NOT
> which is um strange
> and boy do i really hate css uppercase
> 4:49 PM timeless.bmo1: dunno... for the working drafts, probably
> since during this time, people will be quoting it
> if you want to switch back to magical form before final publication,
> perhaps
TYPO: all conformance terms to UPPERCASE.
> timeless.bmo1: i think you want SHOULD here btw
> 4:50 PM A conforming specification may recommend that, aside from including
> standard root certificates, widget user agent allow end-users to install
> digital certificates from other trusted sources.
> this may be a disaster
> we had some guy come to irc.mozilla.org yesterday asking for the ability
> to add his own EV root CA
> 4:51 PM bang head against wall
> MAY at its own peril. :)
> me: hold up, "here" means R37?
> timeless.bmo1: 48
> err 38
> sorry :)
> me: "A conforming specification SHOULD recommend that, aside from including
> standard root certificates, wid"
> 4:52 PM timeless.bmo1: SHOULD NOT :)
> besides, installing a certificate is useless, the only thing worth
> installing is a CA Root
> me: hmm... we had explicit requests for that
ISSUE: should we mandate that developers and admins be allowed to
install their own certs?
> 4:53 PM timeless.bmo1: consider this as a request from the mozilla security
> side
> me: ok
> timeless.bmo1: i'm pretty sure i can get it in writing if necessary
> WUAs are already messy enough, and they're the fast path to rooting the
> device
> 4:54 PM so making it remotely easy to add a Certificate of any kind is not a
> good idea
> me: agreed
> timeless.bmo1: WUAs may provide an Author mode to enable authors to test
> their applications with broken certificates
> 4:55 PM not broken certificates actually
> me: can leave that as an implementation detail
> timeless.bmo1: ok
> can you include a requirement for a security sign off on anything dealing
> w/ certificates? :)
> me: I sure can
ISSUE: need a security sign off on anything dealing w/ certificates.
> timeless.bmo1: the rationale: To allow authors and publisher to sign
> widgets.
> is wrong
> 4:56 PM since publishers can already sign them
> they just need to use a WUA trusted CA root to get their signature
> which is a perfectly reasonable requirement
>
> A conforming specification should recommend that widget user agents allow
> end-users to explicitly input a proxy server through which all HTTP-based
> request are made.
> 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.
> timeless.bmo1: "input" is wrong. it's too strong, perhaps "select"
EDITORIAL: input -> select.
> 5:00 PM and as a should, I SHOULD be able to pick a proxy per widget
> however it shouldn't be a requirement (MUST), because some systems won't
> want to
> me: yeah, that adds quite a bit of complexity
> timeless.bmo1: (not all widgets are created equal, some are more equal than
> others)
> me: sounds like a 2.0 feature
> if someone wants it
> 5:01 PM timeless.bmo1: the problem is that i can easily have some widgets
> that i only want to work in some environments
> and some widgets that will need a proxy at some times
> yeah stupid corporate firewalls
> me: yeah, I can already think of use cases
> timeless.bmo1: however, some things shouldn't work at some times
> 5:02 PM i have apps like this
> which may be ip based and don't want them talking to any random server at
> that ip, but only via some trusted proxy... but i don't want all the other
> widgets to use that trusted proxy
> 5:03 PM or in some cases, i really really don't trust the proxy, but it's a
> necessary evil for a certain widget
> me: you think it might be something to consider for 1.0 then?
> timeless.bmo1: sadly yes
ISSUE: End users should be able to specify that a widget only
communicates via a particular proxy.
> Updating must preserve the identity of the widget and should be conducted
> over a secure communication channel.
> there's a 'should' w/o upper case there
TYPO: FIXED
> 5:04 PM then the widget user agent could ask the end-user if they want to
> download the widget.
> 5:05 PM WUA: there's an update for World Clock available, it's 10mb, your
> current bandwidth is 2bpm, and your rate charge is 10EUR/b. Update now? Yes,
> Never.
> that's going to be the default impl, minus the helpful warning about bad
> speed and high cost
> there needs to be a way for the user to defer answers until the user is
> more willing
EDITORIAL: I've rewritten R40. Automatic Updates "A conforming
specification MUST specify a model to allow widget user agents to
automatically check if a new version of a widget resource has become
available online or from local storage. A conforming specification
MUST recommend that an updated widget is downloaded only with the
user's consent and that users be able to cancel or defer updates. An
automatic update MUST preserve the identity of a widget, meaning that
that preferences previously set by the user are retained after the
update process. A conforming specification SHOULD recommend that, when
possible, automatic updates be conducted over a secure communication
channel. "
> timeless.bmo1: To allow widgets to be closed and re-instantiated without
> the end-user having reset the preferences for an instantiated widget.
> timeless.bmo1: "preferences" => "settings", probably a semi global but not
> quite automatic change
COMMENT: Keeping preferences for now.
> 5:08 PM are you providing distinct storage for settings and app data?
> For example, when using a weather widget, the end-user will want to store
> the preferred location for weather information, and not be asked to input
> that information again every time the widget is re-instantiated.
> me: ATM we only have widget.preferences
> 5:09 PM yes
> timeless.bmo1: ... the user will not want to wait for the app to get a
> weather forecast just because the device rebooted
> me: one can store that as JSON in the prefs
> 5:10 PM timeless.bmo1: fine by me. again better to change it to settings (or
> however i called it earlier) instead of prefs
> A conforming specification must recommend that a widget user agent allow
> multiple instances of a widget resource to be instantiated and run
> concurrently as separate processes.
> some platforms have very high per process overhead
> 5:11 PM yes it means one widget can hang the desktop or crash it. but hey,
> we're memory limited at 128mb or 256mb :)
> me: Should probably relax that then
> timeless.bmo1: definitely
> me: should or may?
> 5:12 PM timeless.bmo1: "could but probably should not because it will hurt
> embedded systems with limited resources"
> could suggest that implementations which have enough resources should
EDITORIAL: I split R42 into two parts "A conforming specification MUST
recommend that a widget user agent allow multiple instances of a
widget resource to be instantiated. A conforming specification MAY
recommend that implementations which have sufficient resources (CPU,
memory, etc.) run widgets concurrently as separate processes."
> 5:13 PM timeless.bmo1: To allow multiples instances of the same widget to be
> run at the same time, but possibly be configured differently. For example,
> instantiating two clock widgets where one displays the time for Amsterdam
> and the other displays the time for Boston.
> the example is bad
> see ipod touch clock
> the right reason is because the user may want the two instances to be in
> different locations or views
> i might want to see nyc in analog on one screen in the top right corner
> 5:14 PM and nyc in digital on another screen in the bottom right corner
COMMENT: agree, not the best example, but it gets the point across I think.
> timeless.bmo1: # Insures that widgets won't be able to perform harmful
> operations on end-user's machines or devices.
> 5:15 PM Insures/Ensures. check w/ someone. i think you want the other
> what if i want to use a widget file manager to delete DRM components :)
> or other widgets
> without informed consent :)
> 5:16 PM some operations should be allowed, but only after consulting the
> "user" (or user policy equivalent)
> (yes, i've worked in systems where the user was actually a script and not
> a normal mortal)
> 5:17 PM it might be simpler to define "user" at the top as possibly being a
> robot, policy, automated script, accessibility agent, etc., or maybe a
> child, human, disabled, or animal.
> then you can use "user" freely w/in and i won't keep saying "or user
> policy equivalent" :)
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.
> A conforming specification must specify a default security policy that
> limits the privileges afforded to a widget at runtime.
> not enough instances of 'default'
> 5:18 PM as written, the system has one policy, enforce for all widgets
> either the default one, or a replacement
> what you want is replaceable policies per widget.