Re: [A&E] Last Call comments (1)

On Wed, Sep 30, 2009 at 1:20 PM, Marcin Hanclik
<Marcin.Hanclik@access-company.com> wrote:
> Hi Marcos,
>
>>>> 5.4.2#2.4.1
>>>> ... apply the  rule for dealing with an invalid Zip archive ...
>>>> And
>>>> "In the event that an implementation encounters an invalid Zip archive ...
>>>> In the case the UA is a CC, it must inform the author that the Zip archive
>>>is an invalid Zip archive." From P&C.
>>>>
>>>> Do not play well together.
>>>> The problem is with the WUA and not with the widget, so the correct
>>>information should be provided to the user.
>>>
>>>Sorry. I don't understand the problem, can you elaborate? Are you
>>>saying that all UAs (not just CCs) must inform the end-user of the
>>>error?
> 7.4.2 says:
> "If the user agent cannot write to the storage area (e.g., because it ran out of disk space, or the space quota was exceeded, etc.), apply the  rule for dealing with an invalid Zip archive specified in the [Widgets-Packaging] specification."
>
> The problem is that "the user agent cannot write to the storage area" and the action is related to invalid Zip archive.
> It is possible that the UA will inform the user that the Zip archive is invalid as part of the rule (probably added by the implementers).
> And then the end-user would get notified e.g. that "Widget is corrupted", whereas simply the WUA does not have enough quota.
>

Ok, I see what you mean (though I don't agree with completely... the
problem is actually worst because dealing with invalid widgets is
related to the steps for processing a widget package (woops! so I
screwed up there)).

I changed it to:

"If the user agent cannot write to the storage area (e.g., because it
ran out of disk space, or the space quota was exceeded, etc.),
terminate all processing of this widget. It is recommended that the
user agent inform the end-user of the error."


>>>> @href from <license> and license,
>>>
>>>What is the use case?
> Similar to description, nothing specific.
> I think the rule could be to map the elements and attributes from config.xml to DOM. The spec could then probably be shorter and easily extensible.
>

Yeah, I don't know. That's a pretty radical change. Lets run with what we have.

>>>> icons
>>>
>>>What is the use case? Also, these may be changing dynamically so it
>>>makes things a mess.
> As above, just map what we have in config.xml.

No, it's more complicated than that.

>>>> The above requirements seem contradicting and not prepared for handling the
>>>security policy.
>>>
>>>Which "security policy"?
> Any, specifically the one planned for DAP.

I have not seen this and have no clue what DAP is doing:  I don't know
what is planned (though, you probably do). If there is nothing
concrete, then I think we should push forward with what we have.

> At present we have WARP LCWD as a sample of the security policy.

That's just one piece of the larger security puzzle. It does not deal
with any install-time security stuff, for instance.

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

Received on Wednesday, 30 September 2009 11:41:03 UTC