Re: [whatwg] Proposal for a web application descriptor

[Charles McCathieNevile]

On Thu, 05 May 2011 21:41:24 +0200, Bjartur Thorlacius  
 wrote:



On 5/5/11, Charles McCathieNevile  wrote:

On Thu, 05 May 2011 00:12:06 +0200, Bjartur Thorlacius
 wrote:


On 5/3/11, Cameron Heavon-Jones  wrote:

There are a number of resources which are thought of having an
'application' scope which may make sense to be collated into a
single manifest and with the ability for an agent to manage it as
such.


Yeah, if a single entity edits and signs multiple resources, it's
unreasonable to trust one but not another.


If I understand correctly, I disagree. I might trust a given entity
sometimes, or with some kinds of information, without wanting to simply
say "sure whatever you want". That's probably for the "hard-to-use mode"
in the UI, but I think it's legitimate. In practice, even given  
something
as simple as twitter's geolocation request I *sometimes* allow it to  
know

where I am and sometimes don't.


In that case you wouldn't grant anyone a carte blanche access to your
location, but authorize or forbid each request. I meant that users
probably wouldn't want to permanently authorize http://twitter.com/A
but not http://twitter.com/.

Of course, if the site requests coordinates, it's up to the user
whether they come from /dev/gps or /dev/tty (or /n/3D Globe).


Yeah, in principle. But given that most users aren't going to symlink  
/dev/gps via their hand-crafted code to decide what to say (largely  
because browsers just ask Google where you are instead based on visible  
Wifi) in practice the question is how to build reasonable UI that the  
users actually understand.


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

Re: [whatwg] JSON Playlist Format

[Silvia Pfeiffer]

On Fri, May 6, 2011 at 1:17 AM, Zachary Ozer  wrote:
> Hi WHATWG,
>
> We've been getting some traffic on our forums from users wondering
> about JSON playlist formats. Specifically, because we aren't
> supporting XML playlists in our player in HTML5 mode (setting the
> Access-Control-Allow-Origin headers would be impossible for most of
> our users), they're looking for a JavaScript-friendly way to
> encapsulate their playlists.
>
> A very cursory search turned up JSPF
> (http://wiki.xiph.org/JSPF_Draft), but it appears to be in draft. Are
> y'all aware of any other formats, either in draft or that have been
> released? If no, any idea why no one's done it already?


Probably because an XML format is sufficient for most uses. I've seen
XSPF used in many places - a list is here http://wiki.xiph.org/XSPF
and more complete here: http://www.xspf.org/applications/ .

However, if you want to use XSPF in JSON, it looks like JSPF is the
way to go. I've also found this: http://gonze.com/xspfgate/ which is a
conversion service from XSPF to JSPF and there's also this
https://github.com/jchris/xspf-to-jspf-parser/blob/master/xspf_parser_runner.html
. But it seems most of the discussion/development about JSFP was in
2008 when Chris Anderson wanted it for his grabb.it company (which
doesn't seem to have survived).

If you have a need for JSON and seeing that XSPF is a widely used
format for playlists, it seems to me using JSPF is the right way
forward. Also, as per your concerns, JSPF doesn't need any
specification of its own, since it's just a different representation
of XSPF IMHO.

Cheers,
Silvia.

Re: [whatwg] JSON Playlist Format

[Zachary Ozer]

The use case I'm thinking of is a blogging service that allows a
publisher to upload static files, but they cannot host executable code
like a proxy. They could include a 

Re: [whatwg] Proposal for a web application descriptor

[Bjartur Thorlacius]

On 5/5/11, Charles McCathieNevile  wrote:
> On Thu, 05 May 2011 00:12:06 +0200, Bjartur Thorlacius
>  wrote:
>
>> On 5/3/11, Cameron Heavon-Jones  wrote:
>>> There are a number of resources which are thought of having an
>>> 'application' scope which may make sense to be collated into a
>>> single manifest and with the ability for an agent to manage it as
>>> such.
>>>
>> Yeah, if a single entity edits and signs multiple resources, it's
>> unreasonable to trust one but not another.
>
> If I understand correctly, I disagree. I might trust a given entity
> sometimes, or with some kinds of information, without wanting to simply
> say "sure whatever you want". That's probably for the "hard-to-use mode"
> in the UI, but I think it's legitimate. In practice, even given something
> as simple as twitter's geolocation request I *sometimes* allow it to know
> where I am and sometimes don't.
>
In that case you wouldn't grant anyone a carte blanche access to your
location, but authorize or forbid each request. I meant that users
probably wouldn't want to permanently authorize http://twitter.com/A
but not http://twitter.com/.

Of course, if the site requests coordinates, it's up to the user
whether they come from /dev/gps or /dev/tty (or /n/3D Globe).

Re: [whatwg] Media elements statistics

[Jeroen Wijering]

On May 5, 2011, at 7:04 PM, Steve Lacey wrote:

> Would jitter be calculated over decodedFrames or decodedFrames+droppedFrames? 
> In the first case, jitter is a more granular metric for measuring exact 
> presentation performance. In the latter case, jitter can serve as a single 
> metric for tracking processing power (simple!). In either case, it's fairly 
> straightforward to calculate towards the other metric.
> 
> Actually, I would expect presentedFrames + droppedFrames would be used. This 
> implies all decoded frames that were supposed to be presented.

Ah yes, sorry. That makes sense. presentedFrames of course need to be included. 

- Jeroen

Re: [whatwg] Media elements statistics

[Steve Lacey]

On Thu, May 5, 2011 at 2:54 AM, Jeroen Wijering wrote:

> Hey Steve,
>
> This looks great; would be a really useful set of data for video players /
> publishers. Since none of the metrics have a time component, developers can
> sample the data over the window / at the frequency they prefer.
>
> Would jitter be calculated over decodedFrames or
> decodedFrames+droppedFrames? In the first case, jitter is a more granular
> metric for measuring exact presentation performance. In the latter case,
> jitter can serve as a single metric for tracking processing power (simple!).
> In either case, it's fairly straightforward to calculate towards the other
> metric.
>

Actually, I would expect presentedFrames + droppedFrames would be used. This
implies all decoded frames that were supposed to be presented.


>
> Resetting the values when @src changes is a good idea. Changing @src is
> much used for advertising and playlist support (it works around iOS not
> supporting the play() call).
>
> Kind regards,
>
> Jeroen Wijering
>
>
>
> On May 3, 2011, at 12:15 AM, Steve Lacey wrote:
>
> > All,
> >
> > I've updated the wiki with a proposal...
> >
> > http://wiki.whatwg.org/wiki/Video_Metrics#Proposal
> >
> > Cheers!
> > Steve
> >
> > On Sat, Apr 9, 2011 at 7:08 AM, Silvia Pfeiffer <
> silviapfeiff...@gmail.com> wrote:
> > Ah, thanks for the link. I've included Silverlight stats, too, for
> > completeness. If somebody knows about QuickTime stats, that would be
> > another good one to add, I guess.
> >
> > Cheers,
> > Silvia.
> >
> > On Fri, Apr 8, 2011 at 5:21 PM, Jeroen Wijering
> >  wrote:
> > >
> > > On Apr 7, 2011, at 8:11 AM, Silvia Pfeiffer wrote:
> > >
> > >> I've also just added a section with the stats that the Adobe Flash
> > >> player exposes.
> > >
> > > Great. Perhaps Silverlight stats might be of use too - though they're
> fairly similar:
> > >
> > >
> http://learn.iis.net/page.aspx/582/advanced-logging-for-iis-70---client-logging/
> > >
> > >> Apart from the statistics that are not currently available from the
> > >> HTML5 player, there are stats that are already available, such as
> > >> currentSrc, currentTime, and all the events which can be turned into
> > >> hooks for measurement.
> > >
> > > Yes, the network and ready states are very useful to determine if
> clients are stalling for buffering etc.
> > >
> > >> I think the page now has a lot of analysis of currently used stats -
> > >> probably a sufficient amount. All the video publishing sites likely
> > >> just use a subpart of the ones that Adobe Flash exposes in their
> > >> analytics.
> > >
> > > Especially all the separate A/V bytecounts are overkill IMO.
> > >
> > > One useful metric I didn't list for JW Player but is very nice is
> Flash's "isLive" property.
> > >
> > > Kind regards,
> > >
> > > Jeroen
> > >
> > >
> > >
> > >
> > >> On Thu, Apr 7, 2011 at 4:52 AM, Mark Watson 
> wrote:
> > >>> All,
> > >>>
> > >>> I added some material to the wiki page based on our experience here
> at Netflix and based on the metrics defined in MPEG DASH for adaptive
> streaming. I'd love to here what people think.
> > >>>
> > >>> Statistics about presentation/rendering seem to be covered, but what
> should also be considered are network performance statistics, which become
> increasingly difficult to collect from the server when sessions are making
> use of multiple servers, possibly across multiple CDNs.
> > >>>
> > >>> Another aspect important for performance management is error
> reporting. Some thoughts on that on the page.
> > >>>
> > >>> ...Mark
> > >>>
> > >>> On Mar 31, 2011, at 7:07 PM, Robert O'Callahan wrote:
> > >>>
> >  On Fri, Apr 1, 2011 at 1:33 PM, Chris Pearce 
> wrote:
> > 
> > > On 1/04/2011 12:22 p.m., Steve Lacey wrote:
> > >
> > >> Chris - in the mozilla stats, I agree on the need for a frame
> count of
> > >> frames that actually make it the the screen, but am interested in
> why we
> > >> need both presented and painted? Wouldn't just a simple
> 'presented' (i.e.
> > >> presented to the user) suffice?
> > >>
> > >>
> > > We distinguish between "painted" and "presented" so we have a
> measure of
> > > the latency in our rendering pipeline. It's more for our benefit as
> browser
> > > developers than for web developers.
> > >
> > 
> >  Yeah, just to be clear, we don't necessarily think that everything
> in our
> >  stats API should be standardized. We should wait and see what
> authors
> >  actually use.
> > 
> >  Rob
> >  --
> >  "Now the Bereans were of more noble character than the
> Thessalonians, for
> >  they received the message with great eagerness and examined the
> Scriptures
> >  every day to see if what Paul said was true." [Acts 17:11]
> > 
> > >>>
> > >>>
> > >
> > >
> >
>
>

Re: [whatwg] JSON Playlist Format

[Nils Dagsson Moskopp]

Zachary Ozer  schrieb am Thu, 5 May 2011
11:17:42 -0400:

> We've been getting some traffic on our forums from users wondering
> about JSON playlist formats. Specifically, because we aren't
> supporting XML playlists in our player in HTML5 mode (setting the
> Access-Control-Allow-Origin headers would be impossible for most of
> our users), they're looking for a JavaScript-friendly way to
> encapsulate their playlists.  

Which would also need CORS measures, or am I mistaken here?

> A very cursory search turned up JSPF
> (http://wiki.xiph.org/JSPF_Draft), but it appears to be in draft. Are
> y'all aware of any other formats, either in draft or that have been
> released? If no, any idea why no one's done it already?  

Probably because fallback to a proxy is way easier.
Anything blocking the use of XSPF + pass-through proxies?


Cheers,
-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] questions regarding submit event timing

[Jonas Sicking]

On Thursday, May 5, 2011, Hallvord R M Steen  wrote:
> (Thanks to those clarifying the sync/async event question  :-))
>
> 2011/5/3 Jonas Sicking :
>> Isn't the purpose of this flag mostly backwards compatibility, but
>> otherwise a fairly awkward feature. If so, it seems like we should
>> limit its scope as much as possible, both to make implementation
>> easier, and to make the forms API otherwise as simple as we can.
>
> It seems to have two purposes:
> 1) avoid doing form validation on form.submit()
> Definitely a backwards compatibility feature, and one that yours truly
> probably caused by complaining when form.submit() was specified to
> throw an exception when the form didn't validate. This broke websites
> left, right and center when implemented in Opera.
>
> 2) Avoid firing a submit event.
> What is more intuitive for button.click() or a synthetic click event
> on the button - submit event firing? I guess so, in that case the spec
> as-is is OK though it's a bit counter-intuitive that other scripted
> ways to submit a form than .submit() don't set the scripted-submit
> flag.

>From a behavioral perspective I think it's most intuitive that the
events fire and that validation occurs. That way calling .click()
behaves as if the user clicked.

However I agree that a name like "scripted-submit" could be
interpreted to mean that it should include other things than calls to
.submit.

Maybe renaming the flag would make the spec more intuitive?

/ Jonas

[whatwg] JSON Playlist Format

[Zachary Ozer]

Hi WHATWG,

We've been getting some traffic on our forums from users wondering
about JSON playlist formats. Specifically, because we aren't
supporting XML playlists in our player in HTML5 mode (setting the
Access-Control-Allow-Origin headers would be impossible for most of
our users), they're looking for a JavaScript-friendly way to
encapsulate their playlists.

A very cursory search turned up JSPF
(http://wiki.xiph.org/JSPF_Draft), but it appears to be in draft. Are
y'all aware of any other formats, either in draft or that have been
released? If no, any idea why no one's done it already?

Best,

Zach
--
Zachary Ozer
Developer, LongTail Video

w: longtailvideo.com • e: z...@longtailvideo.com • p: 212.244.0140 •
f: 212.656.1335
JW Player  |  Bits on the Run  |  AdSolution

Re: [whatwg] Proposal for a web application descriptor

[Charles McCathieNevile]

On Thu, 05 May 2011 16:39:53 +0200, Cameron Heavon-Jones  
 wrote:




On 05/05/2011, at 8:30 AM, timeless wrote:

On Thu, May 5, 2011 at 9:13 AM, Charles McCathieNevile  
 wrote:



In practice, even given something as simple
as twitter's geolocation request I *sometimes* allow it to know where  
I am

and sometimes don't.


I'm hoping we'll eventually move to a model where users are able to
provide default values for things, e.g. "If anyone asks [about
GeoPositioning], I'm in Paris" (I'm currently sick in HEL, but no one
needs to know that).


That sounds like a pretty cool feature, whoever said that the UA had to  
tell the truth! :)


It definitely puts the user in control.


There is a Unite application for Opera that does this -  
http://unite.opera.com/application/701/


cheers

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

Re: [whatwg] Proposal for a web application descriptor

[Cameron Heavon-Jones]

On 05/05/2011, at 8:30 AM, timeless wrote:

> On Thu, May 5, 2011 at 9:13 AM, Charles McCathieNevile  
> wrote:
> 
>> In practice, even given something as simple
>> as twitter's geolocation request I *sometimes* allow it to know where I am
>> and sometimes don't.
> 
> I'm hoping we'll eventually move to a model where users are able to
> provide default values for things, e.g. "If anyone asks [about
> GeoPositioning], I'm in Paris" (I'm currently sick in HEL, but no one
> needs to know that).

That sounds like a pretty cool feature, whoever said that the UA had to tell 
the truth! :)

It definitely puts the user in control.

cam

Re: [whatwg] Proposal for a web application descriptor

[Cameron Heavon-Jones]

On 05/05/2011, at 7:13 AM, Charles McCathieNevile wrote:

> On Thu, 05 May 2011 00:12:06 +0200, Bjartur Thorlacius  
> wrote:
> 
>> On 5/3/11, Cameron Heavon-Jones  wrote:
> 
>>> There are a number of resources which are thought of having an 
>>> 'application' scope which may make sense to be collated into a
>>> single manifest and with the ability for an agent to manage it as
>>> such.
>>> 
>> Yeah, if a single entity edits and signs multiple resources, it's
>> unreasonable to trust one but not another.
> 
> If I understand correctly, I disagree. I might trust a given entity 
> sometimes, or with some kinds of information, without wanting to simply say 
> "sure whatever you want". That's probably for the "hard-to-use mode" in the 
> UI, but I think it's legitimate. In practice, even given something as simple 
> as twitter's geolocation request I *sometimes* allow it to know where I am 
> and sometimes don't.

Yes, i would regard geo location to be dependant on other factors than just who 
is requesting the information. 

In private scenarios i may want an app to always have access to my location if 
it is just augmenting or fixing an information service around my location, but 
in the case of publishing like twitter i would only want to grant access to 
that information on a case by case basis probably defaulting to no. 

There is the problem with granting access to location that once it is given it 
can not be rescinded, at least for a unique session and not accounting for the 
user moving around.

cam

Re: [whatwg] Specification of window.find()

[Hallvord R M Steen]

2011/5/3 Benjamin Poulain :

> I don't really have an interest in defending the feature.
>
> I was just hoping to get a specification for the API to get a bit more
> consistency between engines.
>
> Since you do not seem interested in the feature, I guess we can keep it as a
> WebKit/Gecko extension.

Opera is regularly nagged by rich text editor authors who would like
us to support window.find(). Since it seems to be a requested feature,
it would be nice to have a proper spec ;-)

I guess that one of the main use cases indeed is to be able to
highlight search hits inside a single frame (using the browser's
built-in search might highlight hits both in a rich text editor's UI
and the document you're editing, which would be confusing)..

Yes, it is a counter-argument that authors could write their own
implementation. However, it's non-trivial to write a good text find
implementation in JS - it needs to handle text wrapping, text that is
split across different text nodes or tags, HTML entities, soft
hyphens, BiDi and probably a lot of issues I'm not aware of. It's a
lot simpler to let the JS author hook into the UA's presumably
superior and better tested algorithm.

-- 
Hallvord R. M. Steen

Re: [whatwg] Proposal for a web application descriptor

[Cameron Heavon-Jones]

On 04/05/2011, at 11:12 PM, Bjartur Thorlacius wrote:

>> The quantity of permission requests can be managed in an effective manner by
>> the agent allowing the user to store their preferences for the next command
>> or as a universal setting.
>> 
> If you manage to inform users that they'd then be authorizing for
> every purpose, usually without notice, not just for obeying the
> previous command.

I meant that the authorization preferences would need to be stored on an 
application-by-application basis for it to make any sense. If a user authorizes 
an app to use a restricted resource, they could be prompted as to whether that 
resource should have access granted for future actions.

There could also be the possibility of allowing - or at least being able to 
specify - authorization at a global level. Something like - grant all 
applications access to the webcam. Or in other words to remove any restrictions 
from a resource.


>> This is similar to what firefox does for launching unknown file types,
>> session restore, or lots of other functions, although it would be in the
>> context of a web application itself.
>> 
> How so?

I see this behaviour in lots of desktop applications, not only for 
authorization requests but any kind of repeated confirmation dialog.

In firefox the first time you close the browser it asks if you would like it to 
store the current session for restoration at next startup, this is always shown 
for a fresh install but the dialog has a checkbox for whether the user would 
like firefox to remember their preference and apply that preference without 
confirmation next time firefox shuts down.

I also see this behaviour in Eclipse, which was one of the first desktop 
applications i was aware of to use this UI pattern.

It is valuable as it maintains that the initial default should be to inform and 
ask the user what to do, but also makes it easy for the user to specify that 
they never want to be asked again.

>> For web applications to specify their required permissions would seem to
>> introduce a duplication of specification. If a web application includes an
>> image file upload which the user chooses to capture from webcam, first how
>> is the application to know that the user would use a web cam? and second
> It isn't to know, nor to care. It receives an image, not a camera.

Yes, i thought about this some more and i'm less certain of a direct need for a 
system-level (OS) resource authorization mechanism. 

Why would a user need to be asked if they want to use their own camera?

If they have clicked on a file upload, the OS has displayed a file dialog box, 
then they have chosen to capture from webcam - why would they need to be asked 
if that was authorized? Since the command is from direct user action, and the 
dialog box is an OS user interface, where is the need for a user to confirm 
that what they're doing should be allowed? 

Web sites\Web applications are already isolated from the underlying OS and 
protected from directly accessing system resources. They operate under direct 
user action and not as demon processes so the user is always both the source of 
command and, of course, the authority for granting permission. 

So, without consideration for future APIs, what system-resource authorization 
is actually required by a web application?

The main driver for this would seem to be access to a user's geo location. This 
is more a request for information, not really for resource access. It might be 
better to think about the problem specifically within this use-case and how it 
should be applied as i am unsure of any need for additional authorization 
mechanisms at present.


>> There are a number of resources which are thought of having an 'application'
>> scope which may make sense to be collated into a single manifest and with
>> the ability for an agent to manage it as such.
>> 
> Yeah, if a single entity edits and signs multiple resources, it's
> unreasonable to trust one but not another.

My personal opinion is that what this proposal really highlights the need for 
is a method of packaging or defining the scope and context of what a "Web 
Application" is and its boundaries within a URI space. Without this user agents 
will not have the context necessary to provide configuration and management of 
applications other than over an entire domain xor a single page.

Thanks,
Cameron Jones

Re: [whatwg] questions regarding submit event timing

[Hallvord R M Steen]

(Thanks to those clarifying the sync/async event question  :-))

2011/5/3 Jonas Sicking :
> Isn't the purpose of this flag mostly backwards compatibility, but
> otherwise a fairly awkward feature. If so, it seems like we should
> limit its scope as much as possible, both to make implementation
> easier, and to make the forms API otherwise as simple as we can.

It seems to have two purposes:
1) avoid doing form validation on form.submit()
Definitely a backwards compatibility feature, and one that yours truly
probably caused by complaining when form.submit() was specified to
throw an exception when the form didn't validate. This broke websites
left, right and center when implemented in Opera.

2) Avoid firing a submit event.
What is more intuitive for button.click() or a synthetic click event
on the button - submit event firing? I guess so, in that case the spec
as-is is OK though it's a bit counter-intuitive that other scripted
ways to submit a form than .submit() don't set the scripted-submit
flag.

-- 
Hallvord R. M. Steen

Re: [whatwg] Media elements statistics

[Jeroen Wijering]

Hey Steve,

This looks great; would be a really useful set of data for video players / 
publishers. Since none of the metrics have a time component, developers can 
sample the data over the window / at the frequency they prefer. 

Would jitter be calculated over decodedFrames or decodedFrames+droppedFrames? 
In the first case, jitter is a more granular metric for measuring exact 
presentation performance. In the latter case, jitter can serve as a single 
metric for tracking processing power (simple!). In either case, it's fairly 
straightforward to calculate towards the other metric.

Resetting the values when @src changes is a good idea. Changing @src is much 
used for advertising and playlist support (it works around iOS not supporting 
the play() call).

Kind regards,

Jeroen Wijering



On May 3, 2011, at 12:15 AM, Steve Lacey wrote:

> All,
> 
> I've updated the wiki with a proposal...
> 
> http://wiki.whatwg.org/wiki/Video_Metrics#Proposal
> 
> Cheers!
> Steve
> 
> On Sat, Apr 9, 2011 at 7:08 AM, Silvia Pfeiffer  
> wrote:
> Ah, thanks for the link. I've included Silverlight stats, too, for
> completeness. If somebody knows about QuickTime stats, that would be
> another good one to add, I guess.
> 
> Cheers,
> Silvia.
> 
> On Fri, Apr 8, 2011 at 5:21 PM, Jeroen Wijering
>  wrote:
> >
> > On Apr 7, 2011, at 8:11 AM, Silvia Pfeiffer wrote:
> >
> >> I've also just added a section with the stats that the Adobe Flash
> >> player exposes.
> >
> > Great. Perhaps Silverlight stats might be of use too - though they're 
> > fairly similar:
> >
> > http://learn.iis.net/page.aspx/582/advanced-logging-for-iis-70---client-logging/
> >
> >> Apart from the statistics that are not currently available from the
> >> HTML5 player, there are stats that are already available, such as
> >> currentSrc, currentTime, and all the events which can be turned into
> >> hooks for measurement.
> >
> > Yes, the network and ready states are very useful to determine if clients 
> > are stalling for buffering etc.
> >
> >> I think the page now has a lot of analysis of currently used stats -
> >> probably a sufficient amount. All the video publishing sites likely
> >> just use a subpart of the ones that Adobe Flash exposes in their
> >> analytics.
> >
> > Especially all the separate A/V bytecounts are overkill IMO.
> >
> > One useful metric I didn't list for JW Player but is very nice is Flash's 
> > "isLive" property.
> >
> > Kind regards,
> >
> > Jeroen
> >
> >
> >
> >
> >> On Thu, Apr 7, 2011 at 4:52 AM, Mark Watson  wrote:
> >>> All,
> >>>
> >>> I added some material to the wiki page based on our experience here at 
> >>> Netflix and based on the metrics defined in MPEG DASH for adaptive 
> >>> streaming. I'd love to here what people think.
> >>>
> >>> Statistics about presentation/rendering seem to be covered, but what 
> >>> should also be considered are network performance statistics, which 
> >>> become increasingly difficult to collect from the server when sessions 
> >>> are making use of multiple servers, possibly across multiple CDNs.
> >>>
> >>> Another aspect important for performance management is error reporting. 
> >>> Some thoughts on that on the page.
> >>>
> >>> ...Mark
> >>>
> >>> On Mar 31, 2011, at 7:07 PM, Robert O'Callahan wrote:
> >>>
>  On Fri, Apr 1, 2011 at 1:33 PM, Chris Pearce  wrote:
> 
> > On 1/04/2011 12:22 p.m., Steve Lacey wrote:
> >
> >> Chris - in the mozilla stats, I agree on the need for a frame count of
> >> frames that actually make it the the screen, but am interested in why 
> >> we
> >> need both presented and painted? Wouldn't just a simple 'presented' 
> >> (i.e.
> >> presented to the user) suffice?
> >>
> >>
> > We distinguish between "painted" and "presented" so we have a measure of
> > the latency in our rendering pipeline. It's more for our benefit as 
> > browser
> > developers than for web developers.
> >
> 
>  Yeah, just to be clear, we don't necessarily think that everything in our
>  stats API should be standardized. We should wait and see what authors
>  actually use.
> 
>  Rob
>  --
>  "Now the Bereans were of more noble character than the Thessalonians, for
>  they received the message with great eagerness and examined the 
>  Scriptures
>  every day to see if what Paul said was true." [Acts 17:11]
> 
> >>>
> >>>
> >
> >
> 

Re: [whatwg] Proposal for a web application descriptor

[timeless]

On Thu, May 5, 2011 at 9:13 AM, Charles McCathieNevile  wrote:
> If I understand correctly, I disagree.

:)

> I might trust a given entity
> sometimes, or with some kinds of information, without wanting to simply say
> "sure whatever you want".

And I'm still haunted by web sites which pester me to click on things
before allowing access to content. It's pretty clear that if we let
web sites hold users for ransom, they will (privacy be damned). So we
really should have a model of "privacy secured by default".

> That's probably for the "hard-to-use mode" in the
> UI, but I think it's legitimate.

I'm hoping it isn't that hard.

> In practice, even given something as simple
> as twitter's geolocation request I *sometimes* allow it to know where I am
> and sometimes don't.

I'm hoping we'll eventually move to a model where users are able to
provide default values for things, e.g. "If anyone asks [about
GeoPositioning], I'm in Paris" (I'm currently sick in HEL, but no one
needs to know that). Or "If anyone wants to see what's outside my
window [i.e. visible from my Camera], show them this picture I took
the last time I had sunlight" (In case my cave doesn't have any
lighting).

When a site accesses this information, it should show the user the
information it accesses, and the user (being the one who selected the
information) will understand what it means, if the user wants to give
a different GPS, Picture, etc. to the application, the user would
trigger a site option, and say "allow twitter to see my current
Location ."

Someday I'll try to make a decent mock up of this, I think I'll
eventually publish something @ http://timeless.justdave.net/blog/182/
(no, that url isn't finished, it's only finished when I publish it in
my atom feed)