1029064 - Blobs have no way to compare inner equality

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[Doug Sherk (:drs) (inactive)]

Attachment: Reduced test case

See reduced test case in attachment. This is a problem because we pass around image blobs in Gaia and we don't want to update what we're displaying if the blob is the same as what's already being displayed.

Right now, I believe the best way to get around this is to compare slices, unfortunately.

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Is the request here something like

p = blob.isEqual(otherblob);
p.then((equal) => {
  if (equal === true) {
    alert("they were equal");
  }
  else {
    alert("they were not equal");
  }
});

where isEqual would literally read the entire contents of both blobs until it finds a byte that is different between the two (in which case they are not equal), or until it hits the end of both blobs (in which case they are equal).

Comment 2

[Doug Sherk (:drs) (inactive)]

(In reply to Jonas Sicking (:sicking) from comment #1)
> Is the request here something like
> 
> p = blob.isEqual(otherblob);
> p.then((equal) => {
>   if (equal === true) {
>     alert("they were equal");
>   }
>   else {
>     alert("they were not equal");
>   }
> });
> 
> where isEqual would literally read the entire contents of both blobs until
> it finds a byte that is different between the two (in which case they are
> not equal), or until it hits the end of both blobs (in which case they are
> equal).

Yes, exactly. I think it would also have to check that the types are equal.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

My only concern is that it hides a potentially very long-running and very expensive operation (multiple MB/GB of IO) behind a seemingly small and simple operation.

But I don't have a better proposal really.

Would you mind sending this proposal to public-webapps? Please do include a thorough description of why this is needed.

Comment 4

[Doug Sherk (:drs) (inactive)]

(In reply to Jonas Sicking (:sicking) from comment #3)
> My only concern is that it hides a potentially very long-running and very
> expensive operation (multiple MB/GB of IO) behind a seemingly small and
> simple operation.
> 
> But I don't have a better proposal really.
> 
> Would you mind sending this proposal to public-webapps? Please do include a
> thorough description of why this is needed.

Sure, thanks for your feedback.

Comment 5

[Arun Ranganathan]

(In reply to Doug Sherk (:drs) from comment #0)
> Created attachment 8444612 [details]
> Reduced test case
> 
> See reduced test case in attachment. This is a problem because we pass
> around image blobs in Gaia and we don't want to update what we're displaying
> if the blob is the same as what's already being displayed.
> 
> Right now, I believe the best way to get around this is to compare slices,
> unfortunately.


Just to make sure I understand, currently how exactly are you comparing slices, which also output Blobs?

Comment 6

[Doug Sherk (:drs) (inactive)]

Attachment: Reference implementation in JS

(In reply to Arun K. Ranganathan from comment #5)
> Just to make sure I understand, currently how exactly are you comparing
> slices, which also output Blobs?

Here's a reference implementation with a bit of extra crap around it for the dialer. I ended up not needing this because I forgot that I could just listen for settings changes using SettingsListener. But I could still easily imagine needing this in other situations.

Comment 7

[Andrea Marchesini [:baku]]

(In reply to Jonas Sicking (:sicking) from comment #1)
> Is the request here something like
> 
> p = blob.isEqual(otherblob);
> p.then((equal) => {
>   if (equal === true) {
>     alert("they were equal");
>   }
>   else {
>     alert("they were not equal");
>   }
> });
> 
> where isEqual would literally read the entire contents of both blobs until
> it finds a byte that is different between the two (in which case they are
> not equal), or until it hits the end of both blobs (in which case they are
> equal).

Several optimizations can be done here:

. we can check if the sizes are equals
. if both files are the same kind we can use different compare functions (memcmp for memory files, for instance)

Comment 8

[Arun Ranganathan]

(In reply to Doug Sherk (:drs) from comment #6)
> Created attachment 8445567 [details] [diff] [review]
> Reference implementation in JS
> 
> (In reply to Arun K. Ranganathan from comment #5)
> > Just to make sure I understand, currently how exactly are you comparing
> > slices, which also output Blobs?
> 
> Here's a reference implementation with a bit of extra crap around it for the
> dialer. I ended up not needing this because I forgot that I could just
> listen for settings changes using SettingsListener. But I could still easily
> imagine needing this in other situations.


Aha, ok, you're comparing views on ArrayBuffers, When you said "compare slices" I thought you meant actual usage of Blob.slice which threw me off a bit.

This could well be optimized in the File API with a convenience function. I'm likely to slate it for the FileSystem API, which will have Promise-based semantics anyway.

Comment 9

[Doug Sherk (:drs) (inactive)]

Posted a proposal on public-webapps:
http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0456.html

Comment 10

[Andrea Marchesini [:baku]]

In case we have consensus, can you NI me? I'm happy to work on the implementation.