Re: Widgets

On 2/15/08, Pollington, David, VF-Group <david.pollington@vodafone.com> wrote:
>
> Hi all,
>
> Some initial comments on the Widgets Reqmts doc and Spec:
>
> Requirements:
> - $1.2  Security model; this is stated as being in scope whilst access
> to platforms APIs is currently out of scope.  One approach is that W3C
> focus solely on the security model for Widgets accessing config
> parameters and status info (and nothing else).  But assuming that we
> want to evolve the Widget user agent to also expose (have access to)
> platform APIs (and there is a lot of pull for this), then we need the
> remit of the security model to be a lot broader.

Agreed. As you say, we still need to nail down exactly what the
security model should be for widget UAs. We made some headway at the
last face to face meeting, but we still lack anything concrete on
paper. I've put a call out already to Thomas Roessler for some more
security requirements. Maybe someone else would like to input some
text about the security model?

The issue of widgets having access to device specific
capabilities/APIs has also been the focus of several F2F discussions
in the past. Personally, I am of the position that widgets need such
and API. Numerous people have pointed out that UWA is working on such
an API (see http://www.w3.org/TR/DPF/ for a start), as well as other
consortia (OMA, and JCP), though I'm not totally up-to-date as to
where these groups are at.

Do people think the UWA DPF document is worth exploring? Should widget
UA's implement searchProperty() and hasProperty()?

> - $1.2 Benefits - currently states that it opens the marketplace for new
> vendors to come in with their own Widget user agents which to some
> extent seems to contradict a previous bullet that users will have fewer
> user agents that they need to install.  The aim should be to have one
> Widget user agent per platform (which on a mobile device probably means
> only one user agent on the device) and encourage new entrants to come in
> with their own Widgets hence creating a thriving Widget ecosystem.  A
> final point (which relates to the first bullet) is that rather than
> necessarily enabling any Widget to be run on any Widget user agent, the
> aim should be to enable code re-use; in reality a desktop Widget will
> never be suitable for running directly on a mobile platform without
> optimisation due to the differing UI constraints.

I agree that the mobile UI contraints are different, and your comments
about code reuse, but I'm not sure I agree with having  "one Widget
user agent per platform" (or installing only one widget UA per
platform). Like with browsers, I should be able to choose my preferred
widget UA for a platform; otherwise, who decides what the one true
Widget UA for a platform is?  An eco-system can evolve around many
different widget UAs, as long as they all try to be conformant with
the spec... for example, I choose to use Widget UA X over Y, because X
has super fast JS support, etc.

> - $3 Design goals: Interoperability - I agree with the principle that
> the specification should align with existing Widget user-agents but we
> should also bare in mind that there can be some big differences between
> PC and mobile platforms (and even within PC depending on whether we're
> talking about desktop Widgets or Web page Widgets) so we should still
> keep an eye on what is best long term and what might need to be
> different based on the target platform (in particular mobile vs PC).

I understand the technical constraints, but I'm still having a hard
time seeing how they would affect the spec. I would like to hear more
about the specific technical differences between PC and mobile
platforms, and how we should to attempt to future proof the spec. I
guess what was intended by the interoperability design goal was a
"best-of-breed" approach to creating the spec (which, goes without
saying, really). Having said that, the spec is, and will be, mostly
incompatible with every current widget engines.

> - R10 Data Compression - I take the point that mobile data tariffs might
> currently be considered expensive, but probably not a good idea to
> include this within a standards doc as the situation is likely to
> change.  What we could add though is a comment on battery life - the
> smaller the Widget, the quicker the download and therefore less impact
> on battery life.

I've updated the rational text of R10... however, I'm not sure about
the battery life savings here because the device still needs to
decompress the widget and hence might end up using lots of battery
decompressing resources, etc. However, I don't have any numbers to
back that up with.

> $4.3 Intro para, third bullet needs updating to reflect that device APIs
> are currently out of scope
>
> R31 XHR - my assumption was that this would be mandatory (currently
> 'should' not 'must'); have there been any concerns with making this
> mandatory?  To put it in context, the following reqmt R32 regarding
> inter-Widget communication is a much more advanced concept but also
> currently a 'should'

Our initial idea was that there might be widget engines that don't
support scripting (and hence, no XHR support). However, I think over
time we have concluded that XHR is a must and so is scripting. I've
updated the document; it's now a "must".

> R33 Language Accessibility - I'm guessing when you say non-graphical UI
> you're referring to a tab based UI rather than a mouse/cursor based UI.
> IMHO both approaches should still apply to a graphical UI (?)

Hmm... there I was talking about HTML. HTML does not have to be
graphical. Should I change the text so it's more clear?

> R.37 Persistent Storage - again I think this has to be mandatory
> ('must') as it's such an important feature in the overall user
> experience of using Widgets.  I understand that such status information
> could also stored and retrieved online but the user agent should always
> offer a local storage option.

Agreed. Done.

> R.38 Multiple instances - a comment relating to this (and possibly
> something for section $4.6 on Security) when multiple Widgets are
> instantiated on a given user agent they should be effectively sand-boxed
> to prevent one Widget accessing the config data, status or cache of
> another.  My colleagues in our Security team have been developing our
> own vision for the security model so we should be in a position to
> contribute something shortly.  However, harking back to my previous
> comment, we will need to be clear what the scope of the security model
> is and whether it makes more sense specifying this wherever the device
> API considerations are being held (e.g., OAA, OMTP etc.)

Again, agreed. Hopefully you guys can input something about the security model.

> Some additional comments:
> - UI methods: we've run into problems whereby there has been
> inconsistency in some Widget user agents in the handling of widget UI
> components such as text boxes (selectable in 'mouse/cursor' mode but not
> in tab mode); this is an area that might need some additional
> requirements BUT does it fall within the current charter?

Not sure. Can you give a more specific example? It might turn out that
this is a problem for WebAPI or for the HTML WG?

> - Spec 5.7 Icons - you mention only one permitted but before that in the
> spec it mentions zero or more (I think); anyway we will need support for
> at least 2 icons: a static icon which represents the Widget in the
> Applications folder (for example) and a dynamic icon which can be used
> in a Widget Gallery/Carousel and provide status information for the
> Widget without the Widget needing to be opened full screen.  For example
> a stocks Widget might provide an indication of the current price of a
> share and whether it's up or down; opening the full Widget could then
> provide a detailed chart, comparison against financial indices etc.  To
> be clarified whether the full Widget would need to be instantiated in
> order for the dynamic icon presentation level to be supported...

I've relaxed the spec to allow multiple icons. However, I have not yet
defined a processing model. Are your "dynamic icons" HTML files? I
also think dynamic icons are essential. Dynamic icons are used very
effectively by the Yahoo!'s widget engine and by the iPhone.

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

Received on Friday, 22 February 2008 05:45:23 UTC