Scope of Progress...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Scope of Progress...

Charles McCathieNevile-2

Hi, we are currently at an impasse, where I have been proposing a minimal scope for progress, based on the fact taht anything that can make progress has to already have some defined start and end condition, and Maciej proposes that the progress events include events to identify the start and end position redundantly (allowing you to build widgets for progress events wherever they are found, rather than building for the thing that is going to send the progress events).

We need to find some intelligent way to pick between the two options, since there isn't, as far as I can tell, much of a compromise position that makes sense. On the other hand, if we specify the "fully self-contained" approach, it is possible to write the same kind of code as for the "minimalist integrate with other specs" approach.

I will be asking the SVG working group directly (at their meeting), and other implementors, whether they consider the redundant event generation to be an issue. If not, I am prepared to go with Maciej's proposal. Otherwise I will write up some more detailed examples of how to use the minimalist approach to write UI widgets, following Maciej's example cases.

Does anyone object to us making a First Public Working draft of what we have now? [1]

If we can resolve this issue and the other outstanding ones this week, I would prefer next week to publish something as both First Public Working Draft and Last Call. More or less the entire discussion so far has been public, and it seems that there are only a handful of people who feel strongly one way or the other about these issues (although presumably resolving them per se is important...). There are also implementors who would like this to be resolved quickly.

Such is my plan to get some consensus on one or other approach. If anyone has a better idea, or wants to make it clear that they have an interest in one or other outcome that they have not yet declared, now would be a good time...

[1] http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html

cheers

Chaals

--
  Charles McCathieNevile, Opera Software: Standards Group
  hablo español  -  je parle français  -  jeg lærer norsk
[hidden email]          Try Opera 9.1     http://opera.com

Reply | Threaded
Open this post in threaded view
|

Re: Scope of Progress...

Maciej Stachowiak


On Mar 4, 2007, at 8:48 PM, Charles McCathieNevile wrote:

>
> Hi, we are currently at an impasse, where I have been proposing a  
> minimal scope for progress, based on the fact taht anything that  
> can make progress has to already have some defined start and end  
> condition, and Maciej proposes that the progress events include  
> events to identify the start and end position redundantly (allowing  
> you to build widgets for progress events wherever they are found,  
> rather than building for the thing that is going to send the  
> progress events).

I think that is a somewhat misleading presentation of the  
alternatives. Most possible progress event sources dispatch the same  
error/abort/load events that I suggested incorporating as end events  
into the progress spec, so there is no actual extra event dispatch.  
Most possible progress event sources have no defined start event at  
all (the only way you know it started is you told it to start), so  
that event also would not be redundant.

>
> We need to find some intelligent way to pick between the two  
> options, since there isn't, as far as I can tell, much of a  
> compromise position that makes sense. On the other hand, if we  
> specify the "fully self-contained" approach, it is possible to  
> write the same kind of code as for the "minimalist integrate with  
> other specs" approach.
>
> I will be asking the SVG working group directly (at their meeting),  
> and other implementors, whether they consider the redundant event  
> generation to be an issue. If not, I am prepared to go with  
> Maciej's proposal. Otherwise I will write up some more detailed  
> examples of how to use the minimalist approach to write UI widgets,  
> following Maciej's example cases.
>
> Does anyone object to us making a First Public Working draft of  
> what we have now? [1]
>
> If we can resolve this issue and the other outstanding ones this  
> week, I would prefer next week to publish something as both First  
> Public Working Draft and Last Call. More or less the entire  
> discussion so far has been public, and it seems that there are only  
> a handful of people who feel strongly one way or the other about  
> these issues (although presumably resolving them per se is  
> important...). There are also implementors who would like this to  
> be resolved quickly.

I think even if the large overall issue were resolved, there would  
still be many details that need to be reviewed and worked out before  
publishing a Last Call. I think it would be a bad idea to publish  
FPWD and LC at the same time.

> Such is my plan to get some consensus on one or other approach. If  
> anyone has a better idea, or wants to make it clear that they have  
> an interest in one or other outcome that they have not yet  
> declared, now would be a good time...

Regards,
Maciej