Re: [Widgets] Brief feedback

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?
I also kinda like config;  it's easy to remember... but we will continue 
to look at all possible name options for this element.
>> 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.
I also agree. But I would like to investigate this further, particularly 
with Opera's widgets. It would be interesting to see if the defined 
widths and heights of Opera widgets matches the widgets published 
on-line. I also wonder what happens if you give an incorrect size? does 
the widget get clipped? And what happens if the widget dynamically grows 
in size beyond the defined width and height?

> Other comments:
>
> - <widgetname> should be renamed to <name>
Agreed that it should be changed. Again, the more suggestions of what 
this element should be renamed to the better.

> - should support multiple authors
Agreed. I don't see any harm in supporting multiple authors, even, as Ed 
pointed out, if there are currently very few examples of widgets having 
more than one author. 

> - the security tag should be dropped or reviewed
It will be extensively reviewed, but will probably not dropped. The WG 
is still gathering inputs for this section, so please send more comments.
> - should not require that a widget is packaged at the root of the zip 
> file
I think this is already flagged to change.

As a separate note, HTML will not be the only UI language supported by 
the spec. We want  the manifest to provide a mechanism to start the 
application, such as referencing an initial application file to run 
(which means that the main file does not need to be in the root of the 
package). This is obviously done to accommodate implementations, such as 
Yahoo!'s Widget Engine, that don't use  HTML to declare the UI.

> - The Widget Scripting Interfaces should be dropped or reviewed. In 
> particular, the geometry methods since this wouldn't make sense on 
> some widget runners
They will be extensively reviewed, but probably not dropped at this 
point. Need further research into this issue.

> - should mention a XML NS for the format
If possible, I personally want to avoid namespaces... or at least make 
the namespaces as unobtrusive as possible. Authors don't like them, 
vendors don't seem to be using them for widgets, and they add 
undesirable level of complexity for everyone. Also, one of our design 
goals for this document is ease of use [1], so we want to make this spec 
as easy to use as possible (without compromising extensibility and 
flexibility too much). However, please provide more input as to why XML 
NS should be mentioned... I'll just say, if we can keep things at this 
level, I don't think anyone will have massive problems:

<widget xmlns="http://www.w3.org/ns/widgets">
 
> - should mention a strategy for both embedding the config information 
> inside the widget and reference the config information from the widget
Regarding your first point ("strategy for embedding the config 
information inside the widget"), good idea. Any suggestions? Regarding 
referencing the config information from inside the widget, the current 
(limited) defined strategy for referencing the config info is through 
the API (preferenceForKey, setPreferenceForKey). However, is currently 
underspecified and we need to develop it further.

Marcos

Received on Monday, 13 November 2006 03:21:46 UTC