On Nov 10, 2006, at 3:52 AM, Gorm Haug Eriksen wrote:
On Fri, 10 Nov 2006 06:44:23 +0100, Marcos Caceres
<[EMAIL PROTECTED]> 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
