Hi Rainer,
Thanks for your email and for taking the time to do the review.
On Tue, Oct 14, 2008 at 7:02 AM, Hillebrand, Rainer
[EMAIL PROTECTED] wrote:
Dear Marcos,
I have some comments on the FPWD of the Widgets 1.0: Updates document.
a) Abstract: Replace [...] the model makes use a simple XML documents [...]
by [...] the model makes use of a simple XML document [...].
fixed.
b) 2. Introduction: Replace [...] a multi-step process where by a widget
user agent compares [...] by [...] a multi-step process where a widget user
agent compares [...].
fixed.
c) 2. Introduction: Replace [...] the widget user agent must attempt replace
[...] by [...] the widget user agent must attempt to replace [...].
fixed.
d) 2. Introduction: Replace [...] via the rules define in this specification
[...] by [...] via the rules defined in this specification [...].
fixed.
e) 2. Introduction: Replace [...] then that installed widget is said to be
up-to-date. by [...] then that installed widget resource is said to be
up-to-date..
fixed.
f) 2. Introduction: It is expected that widget user agents will perform
updates asynchronously by periodically checking for changes in either the
HTTP response codes for the UDD (e.g. a changed HTTP Etag header or using
If-Modified-Since) and by processing the UDD itself. This scenario is very
likely in case of an implementation for a desktop computer or a set-top box.
However, a push mechanism is well established in the mobile environment. Such
a push mechanism consists of an SMS message that wakes up an application in a
mobile terminal that retrieves any kind of content from a remote server. It
could be applied to the automatic widget resource update mechanism as well.
The widget resource author would send out notifications to his/her known
customers/users via SMS. The widget user agent retrieves the UDD via HTTP.
The advantage of this push mechanism is that it does not consume unnecessary
processing resources in the mobile terminal and the remote server, does not
consume unnecessary transmission capacity in the Web and updates a widget
resource as soon as an update is available. The disadvantage is that it is
not supported in the IP world. However, we could mention in the specification
that a push mechanism could be applied as well. We could add the following
sentence to the sentence above: A push mechanism could be applied as well
that pushes a UDD to the widget user agent as soon as an update is
available..
Added your suggested text, but as a note: until we have more details
about how we could do this. Is there a spec that outlines this SMS
functionality? Also, this sounds like a firm requirement so I've added
to the widgets version 2.0 requirements (unfortunately, our second
last call for requirements finished yesterday so I'm a bit reluctant
to add support for another features... however, this one sounds like a
good one worth exploring in the future):
http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R#Features_Wish_List
f) 2. Introduction: Replace [...] as it makes us of the URI to potentially
retrieve [...] by [...] as it makes use of the URI to potentially retrieve
[...].
g) 2. Introduction: [...] and relay whether an update is available back to
the instantiated Widget. Actually performing the update is left to the
discretion of the widget user agent. Shall the instantiated Widget be able
to initiate the update process after receiving the information that an update
is available? Otherwise, it would not be under a Widget's control to start
the actual update process. A Widget could be able to consider whether a
mobile terminal is in roaming mode and whether its size is too big. If yes,
it could postpone the update process to avoid unexpected costs for a user. As
soon as the mobile terminal is attached to the home network, the Widget could
ask the user to start the update process.
Good point. However, this sounds like an implementation detail (i.e.,
an really good widget engine would be intelligent enough to hold off
dispatching the update notification event to the instantiated widget
till the time was just right).
h) 4.1 Example Update Description Document: The widgetupdate element supports
two attributes that represent URIs. In section 2. Introduction, it is a IRI
from where the widget user agent can retrieve the potential update, for
instance. If they are the same, then it should be either a URI or an IRI.
Fixed, they are now all URIs. Will add proper IRI support in the next
working draft.
i) 9. Security concerns: It is conceivable that the automatic update model
could be subject to a man-in-the-middle-attack, as with any unencrypted
requests performed over HTTP. For this reason, it is recommended that
automatic update are always performed over HTTPS. An unencrypted request
performed over HTTP is not necessarily opening up a security hole. As long as
a widget
