Re: [Widgets] Brief feedback

On Nov 10, 2006, at 3:52 AM, Gorm Haug Eriksen wrote:

>
> On Fri, 10 Nov 2006 06:44:23 +0100, Marcos Caceres  
> <m.caceres@qut.edu.au> wrote:
>
>> I also agree with Ed in relation to the root node maybe being  
>> called something other than <widget> (for the sake of  
>> accommodating all vendors). Some alternative names off the top of  
>> my head:
>>
>> * <application>, or
>> * <component>, or
>> * <about>, or
>> * <manifest>, or
>> * <metadata>, or
>> * <configuration>
>>
>> Anyone else got any suggestions?
>
> Yea, widget isn't a good name. Perhaps <config> since the file is  
> called config.xml?
>
>> Given that the Widgets 1.0 is based on Opera's config format for  
>> their widgets, I cannot comment as to why or how Opera uses  
>> <width> and <height>.
>
> They are used for the initial width and height of the window.  
> Personally, I think we should have used CSS styling to determine  
> aspect. I agree with Ed that it shouldn't be part of the format.
>
> Other comments:
>
> - <widgetname> should be renamed to <name>
> - should support multiple authors

Hmm. How important is this? Do you mean multiple authors from  
different orgs or the same? I haven't come across too many Widgets to  
date with more than one author (though I can think of one offhand).

> - the security tag should be dropped or reviewed

Yeah, the more I think about this, the more it seems that we really  
don't know all the ins and outs of this aspect of a Widget. I'm  
wondering if it deserves more street time before doing a spec for the  
security block. But when I come up with what we might do here, I can  
throw it out to this list and see what you all think. If we're mostly  
on the same page, maybe there's hope.

> - The Widget Scripting Interfaces should be dropped or reviewed. In  
> particular, the geometry methods since this wouldn't make sense on  
> some widget runners

Yeah, these do seem a little iffy. The preference stuff as it is  
certainly doesn't jive with the way we do preferences. I'm not quite  
sure the Dashboard model is a good one, as it puts all the work on  
the Widget to deal with prefs whereas our current preference system  
makes things quite automatic. I doubt we'd ever want to move to the  
Dashboard way (though I guess I could imagine us supporting it for  
people who really want to use that and present their own preference UI).

> - should mention a strategy for both embedding the config  
> information inside the widget and reference the config information  
> from the widget

Indeed. My plan (for now) was to simply make them properties of our  
Widget object (which they already are). So they'll not be part of the  
DOM, but still accessible for display, etc. by the Widget itself. As  
I type this, it dawns on me we need a version number in there  
(something human readable).

-- Ed

Received on Friday, 10 November 2006 15:47:42 UTC