Re: Lifetime of Blob URL

[David Levin]

On Sun, Jul 11, 2010 at 10:05 PM, Adrian Bateman wrote:

> On Monday, June 28, 2010 2:47 PM, Arun Ranganathan wrote:
> > On 6/23/10 9:50 AM, Jian Li wrote:
> > I think encoding the security origin in the URL allows the UAs to do
> > the security origin check in place, without routing through other
> > authority to get the origin information that might cause the check
> > taking long time to finish.
> >
> > If we worry about showing the double schemes in the URL, we can
> > transform the origin encoded in the URL by using base64 or other
> > escaping algorithm.
> >
> > Jian: the current URL scheme: http://dev.w3.org/2006/webapi/FileAPI/#url
> > allows you to do that, without obliging other UAs to do that.  Some
> > UAs may elect to use "smart caching" to accomplish the same kinds of
> > things, without tagging the URL with origin information.  Others may
> > see benefit in origin-tagging.
> >
> > I've reconsidered trying to architect a scheme that allows all use-case
> > scenarios for blob: URIs.
>
> Hi Arun, I think the updated URL section reflects a good compromise. We
> might want to call out explicitly that "opaque string" should not include
> recognisable metadata to avoid scripts from trying to parse the URL. User
> Agents that wish to include data such as origin should do so by encoding
> it in an opaque manner.
>

Specifying the format of contents of the url is simply an
overspecification. Saying "User Agents that wish to include data such as
origin should do so by encoding it in an opaque manner." is ambiguious. As
soon as anyone publishes the format (which would be trivial to do given
chromium's open source), the format would no longer be opaque.



> I have one other concern about the lifetime of the blob URL [1]. The spec
> currently says that blob: URLs should have the lifetime of the Document.
> I think this is too long. An AJAX style web application may never navigate
> the document and this means that every blob for which a URL is created
> must be kept around in some form for the lifetime of the application.
>
> In our discussions on this topic at Microsoft we've assumed that the
> lifetime for a blob URL will be the same as the lifetime of the blob
> itself.


Making the blob url identical to the lifetime of the blob itself would
expose when garbage collection takes place and in general could lead to easy
to make mistakes in which the developer had something that work mostly but
not always -- your situation below is just one of them.

Check out the Jian Li's alternate proposal (see his response to "Re: [File
API] Recent Updates To Specification + Co-Editor" on July 1, I think) that
addresses this in a way that addresses your concerns and the gc issue as
well.



> This does create something of a race condition. If I have a blob
> representing an image where I set the src of an  element and then
> let the blob go out of scope might it be collected before the  loads
> the resource? We think we'll have to include some mechanism to ensure that
> the blob and URL doesn't get collected before pending network requests
> have been made.
>
> This does impose an additional burden on the web developer: if they later
> want to copy the source URL from one  to another then this will only
> work if they also kept the blob in scope somewhere.
>
> What do you think?
>
> Cheers,
>
> Adrian.
>
> [1] http://dev.w3.org/2006/webapi/FileAPI/#lifeTime
>
>
>

Lifetime of Blob URL

[Adrian Bateman]

On Monday, June 28, 2010 2:47 PM, Arun Ranganathan wrote:
> On 6/23/10 9:50 AM, Jian Li wrote: 
> I think encoding the security origin in the URL allows the UAs to do
> the security origin check in place, without routing through other
> authority to get the origin information that might cause the check
> taking long time to finish.
>
> If we worry about showing the double schemes in the URL, we can
> transform the origin encoded in the URL by using base64 or other
> escaping algorithm.
>
> Jian: the current URL scheme: http://dev.w3.org/2006/webapi/FileAPI/#url
> allows you to do that, without obliging other UAs to do that.  Some
> UAs may elect to use "smart caching" to accomplish the same kinds of
> things, without tagging the URL with origin information.  Others may
> see benefit in origin-tagging.
>
> I've reconsidered trying to architect a scheme that allows all use-case
> scenarios for blob: URIs.

Hi Arun, I think the updated URL section reflects a good compromise. We
might want to call out explicitly that "opaque string" should not include
recognisable metadata to avoid scripts from trying to parse the URL. User
Agents that wish to include data such as origin should do so by encoding
it in an opaque manner.

I have one other concern about the lifetime of the blob URL [1]. The spec
currently says that blob: URLs should have the lifetime of the Document.
I think this is too long. An AJAX style web application may never navigate
the document and this means that every blob for which a URL is created
must be kept around in some form for the lifetime of the application.

In our discussions on this topic at Microsoft we've assumed that the
lifetime for a blob URL will be the same as the lifetime of the blob
itself. This does create something of a race condition. If I have a blob
representing an image where I set the src of an  element and then
let the blob go out of scope might it be collected before the  loads
the resource? We think we'll have to include some mechanism to ensure that
the blob and URL doesn't get collected before pending network requests
have been made.

This does impose an additional burden on the web developer: if they later
want to copy the source URL from one  to another then this will only
work if they also kept the blob in scope somewhere.

What do you think?

Cheers,

Adrian.

[1] http://dev.w3.org/2006/webapi/FileAPI/#lifeTime

Re: Goodbye

[Charles McCathieNevile]

On Sat, 10 Jul 2010 18:38:05 +0200, Doug Schepers  wrote:


Hi, Robert-

Nice to have worked with you.  Good luck in your future endeavors.


Yep, +1 ...

cheers


Regards-
-Doug

Ennals, Robert wrote (on 7/8/10 5:02 PM):

Hi Guys,

I have chosen to leave Intel and so will no longer be representing Intel
in the HTML or WebApps working groups. The other Intel reps in the HTML
WG and the WebApps WG will follow through on the work that I have been
doing, including our distributed extensibility proposals.

If you wish to contact me in the future, please use my personal email
address: r...@ennals.org .

It has been great working with you all.

-Rob





--
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

[Bug 10131] New: Please make it clear that Last-Event-ID has a value that consists of UTF-8 octets. HTTP headers do not have strings.

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10131

   Summary: Please make it clear that Last-Event-ID has a value
that consists of UTF-8 octets. HTTP headers do not
have strings.
   Product: WebAppsWG
   Version: unspecified
  Platform: Other
   URL: http://www.whatwg.org/specs/web-apps/current-work/#pro
cessing-model-4
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: Server-Sent Events (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, ann...@opera.com, public-webapps@w3.org


Section:
http://www.whatwg.org/specs/web-apps/current-work/complete.html#processing-model-4

Comment:
Please make it clear that Last-Event-ID has a value that consists of UTF-8
octets. HTTP headers do not  have strings.

Posted from: 83.85.115.123 by ann...@opera.com

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 10130] New: The steps to "dispatch the event" within EventSource should first remove the LF from the data buffer before checking whether it is empty. Otherwise it can never be empty.

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10130

   Summary: The steps to "dispatch the event" within EventSource
should first remove the LF from the data buffer before
checking whether it is empty. Otherwise it can never
be empty.
   Product: WebAppsWG
   Version: unspecified
  Platform: Other
   URL: http://www.whatwg.org/specs/web-apps/current-work/#dis
patchMessage
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: Server-Sent Events (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, ann...@opera.com, public-webapps@w3.org


Section:
http://www.whatwg.org/specs/web-apps/current-work/complete.html#dispatchMessage

Comment:
The steps to "dispatch the event" within EventSource should first remove the
LF from the data buffer before checking whether it is empty. Otherwise it can
never be empty.

Posted from: 83.85.115.123 by ann...@opera.com

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.