Re: [widgets] Minutes from 12 March 2009 Voice Conference

Hi Robin,
On Mon, Mar 16, 2009 at 5:03 PM, Robin Berjon <robin@berjon.com> wrote:
> Hi Marcos,
>
> On Mar 16, 2009, at 16:00 , Marcos Caceres wrote:
>>
>> On Mon, Mar 16, 2009 at 3:44 PM, Robin Berjon <robin@berjon.com> wrote:
>>>
>>> I would like to echo these concerns. I may have missed something but it
>>> is
>>> still rather unclear to me how making config.xml required improves
>>> security.
>>> I would expect there to be default, security-conscious options that would
>>> apply irrespective of the presence of a config.xml document, and would
>>> also
>>> be the default values for the elements it contains when they are absent.
>>> I
>>> don't have an extremely strong opinion here, but I do see value in making
>>> widget creation as simple as possible: at the simplest, just zip up that
>>> index.svg file you have, rename the zip, and run with it.
>>
>> That's what we were thinking all along. Implementation experience has
>> shown this level of simplicity to be problematic. Adding a config
>> encourages developers to include some metadata. This is a good thing.
>
> I've looked through the archives but I can't find examples of your
> implementation experience, could you point me to it (if you've send it) or
> otherwise describe it? To make my position clear: I'm not virulently against
> mandating config.xml but everything extra we require from developers adds up
> to a cost so I'm likely to push back until presented with strong evidence.

Sorry, I was talking about Opera internal implementation experience
with the current Opera widget engine and config file support.

> I worry about your example of encouraging developers to include metadata: my
> experience is that when you require data from people who don't see the point
> of providing them they either provide gibberish or copy and paste data, and
> bad data are worse than no data at all. Won't people be encourage to provide
> metadata in order to upload their widgets to online repositories? That's a
> case in which the incentive to "do it right" is pretty high and obvious. For
> quick and dirty playing around with something, I know for a fact that I'd
> just copy my config.xml from another widget; requiring it sounds a lot like
> all the noise you have to write around System.out.println("Hello World") in
> Java.

I would point you to any application store and widget gallery on the
web (or iTune's appstore) as evidence that metadata in this space is
heavily used (unlike on web pages). The metadata is highly visible and
extremely important for both authors and users in the distribution
process. I liken not including metadata for an app to not putting your
picture on dating site, you just ain't gonna get any hits :)

>From personal experience using my iphone, I make my buying decisions
for apps based on mostly on  screenshots (the more the better) and
description. That is apart from the categorization and name of app.

>>> The use case of wanting to identify a widget that does not have the media
>>> type or file extension seems to me tenuous at best. In fact, if I happen
>>> to
>>> have a zip archive that happens to contain a config.xml I wouldn't want
>>> anything to assume that it's a widget and I've somehow made a mistake. I
>>> want it treated as a vanilla zip archive until such a time as I decide
>>> otherwise.
>>
>> That's why the namespace is mandatory. That guarantees "widgetness", no?
>
> I'm not sure I follow you, aren't the extension or the media type enough to
> guarantee a file is widgetarian?

Over HTTP, yes. Over Bluetooth (or non-mime type aware sources like
hardisks, or whatever), no.

> Either way, identifying a widget (with
> content sniffing in this case) and trying to encourage best practices are
> different issues; am I right in understanding those are the two reasons you
> have to request this change?

The main reason is that when I'm developing, when I drag my "clock"
(no extension) widget from my desktop to my runtime, it should be able
to be identified as a widget.


Kind regards,
Marcos



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

Received on Tuesday, 17 March 2009 11:40:44 UTC