Re: [Widgets] Requirements LC

On Wed, Jun 18, 2008 at 8:41 PM, timeless <> wrote:
> On 6/18/08, Marcos Caceres <> wrote:
>>  R28. Network State Change Events
>>  A conforming specification must specify a means that allows authors to
>>  check if the widget resource is connected to Web. A conforming
> _the_ Web
> However would you please explain what it means?

Yeah, "the Web" was a poor choice of words:) I've changed it to
"network", but left network to be defined by a conforming
specification. As you pointed out, the concept of connecting
to/disconnecting from a network is quite complex.

> I've I have an iPod Touch and it's connected to a WiFi access point
> which asks me to sign in, and doesn't let me go anywhere until i do
> (but resolves all DNS entries to IP addresses which it answers with
> the same annoying page), am I connected to /the/ Web?

I guess.

>>  specification must also specify a mans by which connection and
> a /means/


>>  disconnection events can be captured by an author through script.
>>  Motivation:
>>  Current development practice or industry best-practices, ease of use.
>>  Rational:
> Rationale ?

right:P Fixed.

>>  To allow authors to programmatically capture when a the widget user
> my spell checker doesn't approve of "programmatically", but I'll deal
> w/ it later.
> "a the" is wrong.


>>  agent has got or lost a connection to the Web.
> don't use "got"

changed to "acquired".

>>  R30. Device Specific APIs and Services
>>  A conforming specification should specify a mechanism, either through
>>  an API or through the configuration document, that allows instantiated
>>  widgets to bind to third-party APIs that allow access to
> that => which


>>  device-specific resources and services. A conforming specification is
>>  not required to specify any APIs to device specific resources or
>>  services, but shouldprovide some means of binding to those APIs if
> should _ _ provide
>>  they are available.


>>  R35. Configuration Document Data
>>  A conforming specification SHOULD specify a means that allows authors
>>  to access any relevant data they declared in the configuration
>>  document for the widget resource.
> i don't understand this, and for privacy reasons, I'm fairly certain i
> disagree with it as written.

This just means that you should be able to get at the stuff in the
config.xml file (so you don't need to declare the metadata again in
the start file). How would you suggest I rewrite it?

>>  To allow author to open a URL in the default system web browser. For
>>  example, in an news aggregator widget, to allow the end user to
> in /a/ news


Many thanks for finding all those errors! If you have any more
comments about the other requirements, I sure would like to hear them.

Marcos Caceres

Received on Thursday, 19 June 2008 01:57:05 UTC