Support sending BlobData to browser process. Also support sending UploadData...

Support sending BlobData to browser process. Also support sending UploadData
with the blob info to browser process.

BUG=none
TEST=none


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=57707

[darin (slow to review), 2010-08-25 04:00:23]

http://codereview.chromium.org/3108042/diff/15002/35008
File chrome/browser/renderer_host/resource_message_filter.h (right):

http://codereview.chromium.org/3108042/diff/15002/35008#newcode80
chrome/browser/renderer_host/resource_message_filter.h:80: };
nit: no trailing ';'

http://codereview.chromium.org/3108042/diff/15002/35020
File chrome/worker/worker_webblobregistry_impl.cc (right):

http://codereview.chromium.org/3108042/diff/15002/35020#newcode19
chrome/worker/worker_webblobregistry_impl.cc:19:
WorkerWebBlobRegistryImpl::WorkerWebBlobRegistryImpl() {
this looks almost identical to RendererWebBlobRegistryImpl.  can you move this
code to common/ and parameterize it with an IPC::Message::Sender instead?

http://codereview.chromium.org/3108042/diff/15002/35025
File net/base/upload_data.h (right):

http://codereview.chromium.org/3108042/diff/15002/35025#newcode79
net/base/upload_data.h:79: void SetToBlobUrl(const GURL& blob_url) {
I think it is wrong to add the concept of BLOB to the net/ module.  It has no
way of interpreting a BLOB URL.

It is only convenient to use this here since we marshal UploadData objects over
IPC.  Perhaps we should stop doing that.

I'll admit that it is a bit unfortunate to have to define yet another structure
to represent WebCore::FormData.  But, that seems to be required given the
layering violation that this CL introduces.

I'm OK with this being a TODO(jianli) though.

http://codereview.chromium.org/3108042/diff/15002/35027
File webkit/blob/blob_data.h (right):

http://codereview.chromium.org/3108042/diff/15002/35027#newcode22
webkit/blob/blob_data.h:22: class BlobData : public base::RefCounted<BlobData> {
add a unit test for this class?

http://codereview.chromium.org/3108042/diff/15002/35027#newcode95
webkit/blob/blob_data.h:95: void toWebBlobData(WebKit::WebBlobData&
web_blob_data) const;
nit: toWebBlobData -> ToWebBlobData

http://codereview.chromium.org/3108042/diff/15002/35029
File webkit/blob/blob_storage_controller.h (right):

http://codereview.chromium.org/3108042/diff/15002/35029#newcode19
webkit/blob/blob_storage_controller.h:19: class BlobStorageController : public
base::RefCounted<BlobStorageController> {
add a unit test for this class?

[michaeln, 2010-08-25 19:36:19]

http://codereview.chromium.org/3108042/diff/15002/35029
File webkit/blob/blob_storage_controller.h (right):

http://codereview.chromium.org/3108042/diff/15002/35029#newcode19
webkit/blob/blob_storage_controller.h:19: class BlobStorageController : public
base::RefCounted<BlobStorageController> {
Since this is created on the UI thread and used on the IO thread, it should be
using a thread safe refcount. And since it contains a collection of refcounted
BlobData that are not refcounted thread safe, we should arrange to have this
destructed on the IO thread (unless we want to make BlobData be a thread safe
refcount).

This is how that was arranged for the AppCacheService class. The
appache::AppCacheService isn't refcounted, and a derived class in the chrome
library adds refcounting semantics.

class ChromeAppCacheService
    : public base::RefCountedThreadSafe<ChromeAppCacheService,
                                        ChromeThread::DeleteOnIOThread>,
      public appcache::AppCacheService .....

Something like that could work for the BlobStorageController class.

Or maybe you can parameterize the 'traits'? 

// webkit_blob
template<typename
TRAITS=DefaultRefCountedThreadSafeTraits<BlobStorageController> >
class BlobStorageController : public RefCountedThreadSafe<BlobStorageController,
TRAITS> { ... };

// chrome
class ChromeBlobStorageController : public
BlobStorageController<ChromeThread::DeleteOnIOThread> {};

Or maybe a chrome level class could use aggregation instead of derivation, I
have in mind to alter the appcache system to use this technique (except with the
appache::AppCacheService class remaining unrefcounted).

// webkit_blob
class BlobStorageController : public base::RefCounted<BlobStorageController>
{...}

// chrome
class ChromeBlobStorageContext : : public
RefCountedThreadSafe<ChromeBlobStorageContext ,
                                                              
ChromeThread::DeleteOnIOThread> {
  scoped_refptr<webkit_blob::BlobStorageContrller> controller_;
}

[jianli, 2010-08-25 23:53:44]

http://codereview.chromium.org/3108042/diff/15002/35008
File chrome/browser/renderer_host/resource_message_filter.h (right):

http://codereview.chromium.org/3108042/diff/15002/35008#newcode80
chrome/browser/renderer_host/resource_message_filter.h:80: };
On 2010/08/25 04:00:23, darin wrote:
> nit: no trailing ';'

Done.

http://codereview.chromium.org/3108042/diff/15002/35020
File chrome/worker/worker_webblobregistry_impl.cc (right):

http://codereview.chromium.org/3108042/diff/15002/35020#newcode19
chrome/worker/worker_webblobregistry_impl.cc:19:
WorkerWebBlobRegistryImpl::WorkerWebBlobRegistryImpl() {
On 2010/08/25 04:00:23, darin wrote:
> this looks almost identical to RendererWebBlobRegistryImpl.  can you move this
> code to common/ and parameterize it with an IPC::Message::Sender instead?

Done.

http://codereview.chromium.org/3108042/diff/15002/35025
File net/base/upload_data.h (right):

http://codereview.chromium.org/3108042/diff/15002/35025#newcode79
net/base/upload_data.h:79: void SetToBlobUrl(const GURL& blob_url) {
On 2010/08/25 04:00:23, darin wrote:
> I think it is wrong to add the concept of BLOB to the net/ module.  It has no
> way of interpreting a BLOB URL.
> 
> It is only convenient to use this here since we marshal UploadData objects
over
> IPC.  Perhaps we should stop doing that.
> 
> I'll admit that it is a bit unfortunate to have to define yet another
structure
> to represent WebCore::FormData.  But, that seems to be required given the
> layering violation that this CL introduces.
> 
> I'm OK with this being a TODO(jianli) though.

Done.

http://codereview.chromium.org/3108042/diff/15002/35027
File webkit/blob/blob_data.h (right):

http://codereview.chromium.org/3108042/diff/15002/35027#newcode22
webkit/blob/blob_data.h:22: class BlobData : public base::RefCounted<BlobData> {
On 2010/08/25 04:00:23, darin wrote:
> add a unit test for this class?

I add a unittest for BlobStorageController, that also tests BlobData since all
its operations are well utilized in BlobStorageController functionalities.

http://codereview.chromium.org/3108042/diff/15002/35027#newcode95
webkit/blob/blob_data.h:95: void toWebBlobData(WebKit::WebBlobData&
web_blob_data) const;
On 2010/08/25 04:00:23, darin wrote:
> nit: toWebBlobData -> ToWebBlobData

This method is not used any more. Removed.

http://codereview.chromium.org/3108042/diff/15002/35029
File webkit/blob/blob_storage_controller.h (right):

http://codereview.chromium.org/3108042/diff/15002/35029#newcode19
webkit/blob/blob_storage_controller.h:19: class BlobStorageController : public
base::RefCounted<BlobStorageController> {
On 2010/08/25 04:00:23, darin wrote:
> add a unit test for this class?

Done.

http://codereview.chromium.org/3108042/diff/15002/35029#newcode19
webkit/blob/blob_storage_controller.h:19: class BlobStorageController : public
base::RefCounted<BlobStorageController> {
On 2010/08/25 19:36:19, michaeln wrote:
> Since this is created on the UI thread and used on the IO thread, it should be
> using a thread safe refcount. And since it contains a collection of refcounted
> BlobData that are not refcounted thread safe, we should arrange to have this
> destructed on the IO thread (unless we want to make BlobData be a thread safe
> refcount).
> 
> This is how that was arranged for the AppCacheService class. The
> appache::AppCacheService isn't refcounted, and a derived class in the chrome
> library adds refcounting semantics.
> 
> class ChromeAppCacheService
>     : public base::RefCountedThreadSafe<ChromeAppCacheService,
>                                         ChromeThread::DeleteOnIOThread>,
>       public appcache::AppCacheService .....
> 
> Something like that could work for the BlobStorageController class.
> 
> Or maybe you can parameterize the 'traits'? 
> 
> // webkit_blob
> template<typename
> TRAITS=DefaultRefCountedThreadSafeTraits<BlobStorageController> >
> class BlobStorageController : public
RefCountedThreadSafe<BlobStorageController,
> TRAITS> { ... };
> 
> // chrome
> class ChromeBlobStorageController : public
> BlobStorageController<ChromeThread::DeleteOnIOThread> {};
> 
> Or maybe a chrome level class could use aggregation instead of derivation, I
> have in mind to alter the appcache system to use this technique (except with
the
> appache::AppCacheService class remaining unrefcounted).
> 
> // webkit_blob
> class BlobStorageController : public base::RefCounted<BlobStorageController>
> {...}
> 
> // chrome
> class ChromeBlobStorageContext : : public
> RefCountedThreadSafe<ChromeBlobStorageContext ,
>                                                               
> ChromeThread::DeleteOnIOThread> {
>   scoped_refptr<webkit_blob::BlobStorageContrller> controller_;
> }

Thanks for noticing this. I choose to do what you suggest last.

[michaeln, 2010-08-26 20:43:05]

Not a full review but some comments

http://codereview.chromium.org/3108042/diff/52002/61004
File chrome/browser/chrome_blob_storage_controller.h (right):

http://codereview.chromium.org/3108042/diff/52002/61004#newcode11
chrome/browser/chrome_blob_storage_controller.h:11: #include
"webkit/blob/blob_storage_controller.h"
is this include needed anymore?

http://codereview.chromium.org/3108042/diff/52002/61004#newcode27
chrome/browser/chrome_blob_storage_controller.h:27: class
ChromeBlobStorageController
idk... is ChromeBlobStorageContext a better name? Not saying it is, just asking.

http://codereview.chromium.org/3108042/diff/52002/61012
File chrome/browser/renderer_host/resource_message_filter.h (right):

http://codereview.chromium.org/3108042/diff/52002/61012#newcode383
chrome/browser/renderer_host/resource_message_filter.h:383: void
OnUnregisterBlobUrl(const GURL& url);
Do we care to put encapsulate these handlers in a BlobDispatcherHost class? That
would provide a tidy place to keep per-child process state too (like the set of
blob urls coined in a given process).

http://codereview.chromium.org/3108042/diff/52002/61016
File chrome/common/common_param_traits.h (right):

http://codereview.chromium.org/3108042/diff/52002/61016#newcode269
chrome/common/common_param_traits.h:269: 
an extra blank line got introduced here

http://codereview.chromium.org/3108042/diff/52002/61023
File chrome/worker/worker_thread.cc (right):

http://codereview.chromium.org/3108042/diff/52002/61023#newcode19
chrome/worker/worker_thread.cc:19: #include
"third_party/WebKit/WebKit/chromium/public/WebBlobRegistry.h"
needed?

http://codereview.chromium.org/3108042/diff/52002/61025
File chrome/worker/worker_webkitclient_impl.h (right):

http://codereview.chromium.org/3108042/diff/52002/61025#newcode74
chrome/worker/worker_webkitclient_impl.h:74: scoped_ptr<WebKit::WebBlobRegistry>
web_blob_registry_;
just blob_registry_, sans 'web' prefix on the data member name.

http://codereview.chromium.org/3108042/diff/52002/61029
File webkit/blob/blob_data.h (right):

http://codereview.chromium.org/3108042/diff/52002/61029#newcode35
webkit/blob/blob_data.h:35: length_(kuint64max) {
why init length to kuint64max instead of 0?

http://codereview.chromium.org/3108042/diff/52002/61029#newcode56
webkit/blob/blob_data.h:56: length_ = length;
we could pull out the range from the given string instead of copying the whole
thing

http://codereview.chromium.org/3108042/diff/52002/61029#newcode127
webkit/blob/blob_data.h:127: void AppendData(const std::string& data, uint32
offset, uint32 length) {
If the item on the back of the list is a 'data' item, you could append this new
data into that existing item (assuming we don't store unneeded data in the
std::string).

I'm looking at this class with an eye to making it deal with deletable temp
files.

fyi... gears blob handling stuff (which spills over to disk if data gets too
large)
http://code.google.com/p/gears/source/browse/trunk/gears/blob/?r=3288
http://code.google.com/p/gears/source/browse/trunk/gears/base/common/byte_sto...

http://codereview.chromium.org/3108042/diff/52002/61030
File webkit/blob/blob_storage_controller.cc (right):

http://codereview.chromium.org/3108042/diff/52002/61030#newcode88
webkit/blob/blob_storage_controller.cc:88: // a set of Data and File items.
Maybe we could keep a reference to constituent blobData's along with an offset
and length into it. You've got these refounted objects (BlobData), but I don't
how them being refcounted in being taken advantage of?

http://codereview.chromium.org/3108042/diff/52002/61030#newcode106
webkit/blob/blob_storage_controller.cc:106: if (src_blob_data.get())
Silently eating this error seems wrong. If the 'src' blob is not found,
something is not right.

http://codereview.chromium.org/3108042/diff/52002/61030#newcode130
webkit/blob/blob_storage_controller.cc:130: blob_map_[url.spec()] =
target_blob_data;
I'm wondering if we just need to keep a second ref to the orig blob data instead
of making a new instance? Once a blob is registered, is it mutable?

http://codereview.chromium.org/3108042/diff/52002/61031
File webkit/blob/blob_storage_controller.h (right):

http://codereview.chromium.org/3108042/diff/52002/61031#newcode19
webkit/blob/blob_storage_controller.h:19: class BlobStorageController : public
base::RefCounted<BlobStorageController> {
Does this need to be refcounted now?

[jianli, 2010-08-26 22:55:51]

http://codereview.chromium.org/3108042/diff/52002/61004
File chrome/browser/chrome_blob_storage_controller.h (right):

http://codereview.chromium.org/3108042/diff/52002/61004#newcode11
chrome/browser/chrome_blob_storage_controller.h:11: #include
"webkit/blob/blob_storage_controller.h"
On 2010/08/26 20:43:05, michaeln wrote:
> is this include needed anymore?

Removed.

http://codereview.chromium.org/3108042/diff/52002/61004#newcode27
chrome/browser/chrome_blob_storage_controller.h:27: class
ChromeBlobStorageController
On 2010/08/26 20:43:05, michaeln wrote:
> idk... is ChromeBlobStorageContext a better name? Not saying it is, just
asking.

Renamed.

http://codereview.chromium.org/3108042/diff/52002/61012
File chrome/browser/renderer_host/resource_message_filter.h (right):

http://codereview.chromium.org/3108042/diff/52002/61012#newcode383
chrome/browser/renderer_host/resource_message_filter.h:383: void
OnUnregisterBlobUrl(const GURL& url);
On 2010/08/26 20:43:05, michaeln wrote:
> Do we care to put encapsulate these handlers in a BlobDispatcherHost class?
That
> would provide a tidy place to keep per-child process state too (like the set
of
> blob urls coined in a given process).

Done.

http://codereview.chromium.org/3108042/diff/52002/61016
File chrome/common/common_param_traits.h (right):

http://codereview.chromium.org/3108042/diff/52002/61016#newcode269
chrome/common/common_param_traits.h:269: 
On 2010/08/26 20:43:05, michaeln wrote:
> an extra blank line got introduced here

Done.

http://codereview.chromium.org/3108042/diff/52002/61023
File chrome/worker/worker_thread.cc (right):

http://codereview.chromium.org/3108042/diff/52002/61023#newcode19
chrome/worker/worker_thread.cc:19: #include
"third_party/WebKit/WebKit/chromium/public/WebBlobRegistry.h"
On 2010/08/26 20:43:05, michaeln wrote:
> needed?

Yes, it is needed because WorkerThread creates WorkerWebKitClientImpl and it
includes:
  scoped_ptr<WebKit::WebBlobRegistry> web_blob_registry_;

The compiler will complain about use of undefined type 'WebKit::WebBlobRegistry
when 'scoped_ptr<C>' being compiled.

http://codereview.chromium.org/3108042/diff/52002/61025
File chrome/worker/worker_webkitclient_impl.h (right):

http://codereview.chromium.org/3108042/diff/52002/61025#newcode74
chrome/worker/worker_webkitclient_impl.h:74: scoped_ptr<WebKit::WebBlobRegistry>
web_blob_registry_;
On 2010/08/26 20:43:05, michaeln wrote:
> just blob_registry_, sans 'web' prefix on the data member name.

Done.

http://codereview.chromium.org/3108042/diff/52002/61029
File webkit/blob/blob_data.h (right):

http://codereview.chromium.org/3108042/diff/52002/61029#newcode35
webkit/blob/blob_data.h:35: length_(kuint64max) {
On 2010/08/26 20:43:05, michaeln wrote:
> why init length to kuint64max instead of 0?

This is to do the same thing as in UploadData. After second thought, I changed
to 0.

http://codereview.chromium.org/3108042/diff/52002/61029#newcode56
webkit/blob/blob_data.h:56: length_ = length;
On 2010/08/26 20:43:05, michaeln wrote:
> we could pull out the range from the given string instead of copying the whole
> thing

This is on purpose because we do not want to create the partial data string.
There could be multiple references to the same original data string, which might
have different ranges, due to slicing differently. We assume that the underlying
string should be smart enough to maintain only one copy.

http://codereview.chromium.org/3108042/diff/52002/61029#newcode127
webkit/blob/blob_data.h:127: void AppendData(const std::string& data, uint32
offset, uint32 length) {
On 2010/08/26 20:43:05, michaeln wrote:
> If the item on the back of the list is a 'data' item, you could append this
new
> data into that existing item (assuming we don't store unneeded data in the
> std::string).
> 
> I'm looking at this class with an eye to making it deal with deletable temp
> files.
> 
> fyi... gears blob handling stuff (which spills over to disk if data gets too
> large)
> http://code.google.com/p/gears/source/browse/trunk/gears/blob/?r=3288
>
http://code.google.com/p/gears/source/browse/trunk/gears/base/common/byte_sto...

I do not want to do this. See the reason above.

We can consider writing the data to the disk if it is too large like what Gears
does. Added a TODO here.

http://codereview.chromium.org/3108042/diff/52002/61030
File webkit/blob/blob_storage_controller.cc (right):

http://codereview.chromium.org/3108042/diff/52002/61030#newcode88
webkit/blob/blob_storage_controller.cc:88: // a set of Data and File items.
On 2010/08/26 20:43:05, michaeln wrote:
> Maybe we could keep a reference to constituent blobData's along with an offset
> and length into it. You've got these refounted objects (BlobData), but I don't
> how them being refcounted in being taken advantage of?

Yes, but when we use it, we have to do the same thing. If we have a blob
pointing to another blob pointing to 3rd blob, we will have to do more
complicated resolving when we use it.

http://codereview.chromium.org/3108042/diff/52002/61030#newcode106
webkit/blob/blob_storage_controller.cc:106: if (src_blob_data.get())
On 2010/08/26 20:43:05, michaeln wrote:
> Silently eating this error seems wrong. If the 'src' blob is not found,
> something is not right.

Added a DCHECK.

http://codereview.chromium.org/3108042/diff/52002/61030#newcode130
webkit/blob/blob_storage_controller.cc:130: blob_map_[url.spec()] =
target_blob_data;
On 2010/08/26 20:43:05, michaeln wrote:
> I'm wondering if we just need to keep a second ref to the orig blob data
instead
> of making a new instance? Once a blob is registered, is it mutable?

Done.

http://codereview.chromium.org/3108042/diff/52002/61031
File webkit/blob/blob_storage_controller.h (right):

http://codereview.chromium.org/3108042/diff/52002/61031#newcode19
webkit/blob/blob_storage_controller.h:19: class BlobStorageController : public
base::RefCounted<BlobStorageController> {
On 2010/08/26 20:43:05, michaeln wrote:
> Does this need to be refcounted now?

Removed.

[michaeln, 2010-08-26 22:56:57]

Also, thank you so much for revamping this to be a chrome centric
implementation!

[michaeln, 2010-08-27 00:36:36]

Thinking about how BlobBuilder is likely to be used, say to construct POST
bodies programatically.

builder.append('Content-Type: multipart/form-data; boundary=');
builder.append(kBoundaryString);
builder.append(kCRLF);
builder.append(kCRLF);
builder.append(fieldName);
.... etc ...

It might be good to collapse consecutive string items somewhere in the system.
Does that happen in the WebCore::BlobBuilder?

http://codereview.chromium.org/3108042/diff/52002/61029
File webkit/blob/blob_data.h (right):

http://codereview.chromium.org/3108042/diff/52002/61029#newcode56
webkit/blob/blob_data.h:56: length_ = length;
On 2010/08/26 22:55:52, jianli wrote:
> On 2010/08/26 20:43:05, michaeln wrote:
> > we could pull out the range from the given string instead of copying the
whole
> > thing
> 
> This is on purpose because we do not want to create the partial data string.
> There could be multiple references to the same original data string, which
might
> have different ranges, due to slicing differently. We assume that the
underlying
> string should be smart enough to maintain only one copy.

I see, do any of our std::string impls do that, I thought they didn't but i'm
not sure? In the current design, the higher level code is expressly making
copies with the hopes that the lower level code is smart enough to avoid copying
bulky data around, but the lower level code actually isn't (i think)... so
ultimately we're making copies of more data than we need to.

idk?

http://codereview.chromium.org/3108042/diff/52002/61029#newcode127
webkit/blob/blob_data.h:127: void AppendData(const std::string& data, uint32
offset, uint32 length) {
> We can consider writing the data to the disk if it is too large like what
Gears
> does. Added a TODO here.

TODO is good.

http://codereview.chromium.org/3108042/diff/63035/37011
File chrome/browser/renderer_host/blob_dispatcher_host.cc (right):

http://codereview.chromium.org/3108042/diff/63035/37011#newcode35
chrome/browser/renderer_host/blob_dispatcher_host.cc:35: bool* msg_is_ok) {
indent

http://codereview.chromium.org/3108042/diff/63035/37012
File chrome/browser/renderer_host/blob_dispatcher_host.h (right):

http://codereview.chromium.org/3108042/diff/63035/37012#newcode23
chrome/browser/renderer_host/blob_dispatcher_host.h:23: : public
base::RefCountedThreadSafe<BlobDispatcherHost> {
Does this need to be refcounted anymore?

http://codereview.chromium.org/3108042/diff/63035/37012#newcode35
chrome/browser/renderer_host/blob_dispatcher_host.h:35: void
OnMessageReceivedWebKit(const IPC::Message& message);
Stale method, can be deleted?

http://codereview.chromium.org/3108042/diff/63035/37012#newcode46
chrome/browser/renderer_host/blob_dispatcher_host.h:46:
base::hash_set<std::string> blob_urls_;
Does GURL work as a key?

http://codereview.chromium.org/3108042/diff/63035/37030
File webkit/blob/blob_data.cc (right):

http://codereview.chromium.org/3108042/diff/63035/37030#newcode26
webkit/blob/blob_data.cc:26: if (!item.data.isEmpty()) {
nit: no need for {}'s here

http://codereview.chromium.org/3108042/diff/63035/37030#newcode35
webkit/blob/blob_data.cc:35:
base::Time::FromDoubleT(item.expectedModificationTime));
length and modification time may be interesting to come up with given just a
filePath in the child process

@jian, are there any inputs to this that mean 'file in its current state' w/o
knowing the length/modTime?

@darin, do downloadToFile results contain this info?

http://codereview.chromium.org/3108042/diff/63035/37032
File webkit/blob/blob_storage_controller.cc (right):

http://codereview.chromium.org/3108042/diff/63035/37032#newcode101
webkit/blob/blob_storage_controller.cc:101: scoped_refptr<BlobData> blob_data =
blob_map_[src_url.spec()];
You could use GetBlobData here and skip loading into a scoped_refptr to avoid a
little refcount churn.

Also, this will insert empty entries if 'src_url' is not in the map which we
probably should avoid.

http://codereview.chromium.org/3108042/diff/63035/37032#newcode113
webkit/blob/blob_storage_controller.cc:113: return blob_map_[url.spec()].get();
This will insert an entry if 'url' is not in the map. I think you want to use
find() to avoid creating empty map entries.

http://codereview.chromium.org/3108042/diff/63035/37033
File webkit/blob/blob_storage_controller.h (right):

http://codereview.chromium.org/3108042/diff/63035/37033#newcode36
webkit/blob/blob_storage_controller.h:36: typedef base::hash_map<std::string,
scoped_refptr<BlobData> > BlobMap;
Does GURL work as a key?

[jianli, 2010-08-27 01:07:41]

> Thinking about how BlobBuilder is likely to be used, say to construct POST
> bodies programatically.
> 
> builder.append('Content-Type: multipart/form-data; boundary=');
> builder.append(kBoundaryString);
> builder.append(kCRLF);
> builder.append(kCRLF);
> builder.append(fieldName);
> .... etc ...

> It might be good to collapse consecutive string items somewhere in the system.
> Does that happen in the WebCore::BlobBuilder?

Yes. Good thought. I will fix this in WebCore::BlobBuilder.

http://codereview.chromium.org/3108042/diff/52002/61029
File webkit/blob/blob_data.h (right):

http://codereview.chromium.org/3108042/diff/52002/61029#newcode56
webkit/blob/blob_data.h:56: length_ = length;
On 2010/08/27 00:36:37, michaeln wrote:
> On 2010/08/26 22:55:52, jianli wrote:
> > On 2010/08/26 20:43:05, michaeln wrote:
> > > we could pull out the range from the given string instead of copying the
> whole
> > > thing
> > 
> > This is on purpose because we do not want to create the partial data string.
> > There could be multiple references to the same original data string, which
> might
> > have different ranges, due to slicing differently. We assume that the
> underlying
> > string should be smart enough to maintain only one copy.
> 
> I see, do any of our std::string impls do that, I thought they didn't but i'm
> not sure? In the current design, the higher level code is expressly making
> copies with the hopes that the lower level code is smart enough to avoid
copying
> bulky data around, but the lower level code actually isn't (i think)... so
> ultimately we're making copies of more data than we need to.
> 
> idk?

WebCore::String supports this semantics. I am not aware that we could have
problem with std::string. Yes, you're right that we should not depend on the
lower level semantics. I think we need to implement some sort of ref counting
vector data. I added a TODO to fix it later. Is it OK to keep the current
implementation for now?

http://codereview.chromium.org/3108042/diff/63035/37011
File chrome/browser/renderer_host/blob_dispatcher_host.cc (right):

http://codereview.chromium.org/3108042/diff/63035/37011#newcode35
chrome/browser/renderer_host/blob_dispatcher_host.cc:35: bool* msg_is_ok) {
On 2010/08/27 00:36:37, michaeln wrote:
> indent

Done.

http://codereview.chromium.org/3108042/diff/63035/37012
File chrome/browser/renderer_host/blob_dispatcher_host.h (right):

http://codereview.chromium.org/3108042/diff/63035/37012#newcode23
chrome/browser/renderer_host/blob_dispatcher_host.h:23: : public
base::RefCountedThreadSafe<BlobDispatcherHost> {
On 2010/08/27 00:36:37, michaeln wrote:
> Does this need to be refcounted anymore?

Removed.

http://codereview.chromium.org/3108042/diff/63035/37012#newcode35
chrome/browser/renderer_host/blob_dispatcher_host.h:35: void
OnMessageReceivedWebKit(const IPC::Message& message);
On 2010/08/27 00:36:37, michaeln wrote:
> Stale method, can be deleted?

Done.

http://codereview.chromium.org/3108042/diff/63035/37012#newcode46
chrome/browser/renderer_host/blob_dispatcher_host.h:46:
base::hash_set<std::string> blob_urls_;
On 2010/08/27 00:36:37, michaeln wrote:
> Does GURL work as a key?

Nope.

http://codereview.chromium.org/3108042/diff/63035/37030
File webkit/blob/blob_data.cc (right):

http://codereview.chromium.org/3108042/diff/63035/37030#newcode26
webkit/blob/blob_data.cc:26: if (!item.data.isEmpty()) {
On 2010/08/27 00:36:37, michaeln wrote:
> nit: no need for {}'s here

Done.

http://codereview.chromium.org/3108042/diff/63035/37030#newcode35
webkit/blob/blob_data.cc:35:
base::Time::FromDoubleT(item.expectedModificationTime));
On 2010/08/27 00:36:37, michaeln wrote:
> length and modification time may be interesting to come up with given just a
> filePath in the child process
> 
> @jian, are there any inputs to this that mean 'file in its current state' w/o
> knowing the length/modTime?
> 
> @darin, do downloadToFile results contain this info?

Yes, when item.length is set to -1 and item.expectedModificationTime is set to
0.

In addition, my proposed fix for base::Time DoubleTToTime is not liked by
davemoore. So I change to use a workaround here.

http://codereview.chromium.org/3108042/diff/63035/37032
File webkit/blob/blob_storage_controller.cc (right):

http://codereview.chromium.org/3108042/diff/63035/37032#newcode101
webkit/blob/blob_storage_controller.cc:101: scoped_refptr<BlobData> blob_data =
blob_map_[src_url.spec()];
On 2010/08/27 00:36:37, michaeln wrote:
> You could use GetBlobData here and skip loading into a scoped_refptr to avoid
a
> little refcount churn.
> 
> Also, this will insert empty entries if 'src_url' is not in the map which we
> probably should avoid.

Done.

http://codereview.chromium.org/3108042/diff/63035/37032#newcode113
webkit/blob/blob_storage_controller.cc:113: return blob_map_[url.spec()].get();
On 2010/08/27 00:36:37, michaeln wrote:
> This will insert an entry if 'url' is not in the map. I think you want to use
> find() to avoid creating empty map entries.

Done.

http://codereview.chromium.org/3108042/diff/63035/37033
File webkit/blob/blob_storage_controller.h (right):

http://codereview.chromium.org/3108042/diff/63035/37033#newcode36
webkit/blob/blob_storage_controller.h:36: typedef base::hash_map<std::string,
scoped_refptr<BlobData> > BlobMap;
On 2010/08/27 00:36:37, michaeln wrote:
> Does GURL work as a key?

It does not work.

[darin (slow to review), 2010-08-27 07:27:30]

OK, LGTM modulo:

http://codereview.chromium.org/3108042/diff/72001/73018
File chrome/common/render_messages_internal.h (right):

http://codereview.chromium.org/3108042/diff/72001/73018#newcode2719
chrome/common/render_messages_internal.h:2719:
scoped_refptr<webkit_blob::BlobData> /* blob_data */)
did you try forward declaring BlobData?

http://codereview.chromium.org/3108042/diff/72001/73028
File net/base/upload_data.h (right):

http://codereview.chromium.org/3108042/diff/72001/73028#newcode80
net/base/upload_data.h:80: // to define another structure to represent
WebCore::FormData.
nit: maybe i should have said WebKit::WebHTTPBody, sorry.  best not to refer to
WebCore'isms from Chromium since the comment can bit-rot more easily.

http://codereview.chromium.org/3108042/diff/72001/73029
File webkit/blob/blob_data.cc (right):

http://codereview.chromium.org/3108042/diff/72001/73029#newcode21
webkit/blob/blob_data.cc:21: // We have to work around this problem here.
this seems a bit unfortunate to me.  there should be some better solution. 
surely, this is not the only piece of code to ever care about preserving 0.

http://codereview.chromium.org/3108042/diff/72001/73029#newcode26
webkit/blob/blob_data.cc:26: };
nit: no ';' here

also, i'd put the anonymous namespace within the webkit_blob namespace.

[brettw, 2010-08-27 15:22:02]

http://codereview.chromium.org/3108042/diff/72001/73029
File webkit/blob/blob_data.cc (right):

http://codereview.chromium.org/3108042/diff/72001/73029#newcode21
webkit/blob/blob_data.cc:21: // We have to work around this problem here.
FromDoubleT should be updated. FromTimeT already handles 0 like you want, and
ToDoubleT even does this going the other way! So it's definitely a bug that the
0 isn't handled there.

[jianli, 2010-08-27 16:51:30]

http://codereview.chromium.org/3108042/diff/72001/73029
File webkit/blob/blob_data.cc (right):

http://codereview.chromium.org/3108042/diff/72001/73029#newcode21
webkit/blob/blob_data.cc:21: // We have to work around this problem here.
On 2010/08/27 15:22:02, brettw wrote:
> FromDoubleT should be updated. FromTimeT already handles 0 like you want, and
> ToDoubleT even does this going the other way! So it's definitely a bug that
the
> 0 isn't handled there.

I've already sent a patch to davemoore for review:
http://codereview.chromium.org/3175044/show

But unfortunately, there're some discussions going on. I will also cc you.

[michaeln, 2010-08-27 18:24:43]

http://codereview.chromium.org/3108042/diff/52002/61029
File webkit/blob/blob_data.h (right):

http://codereview.chromium.org/3108042/diff/52002/61029#newcode56
webkit/blob/blob_data.h:56: length_ = length;
> I added a TODO to fix it later. Is it OK to keep the current
> implementation for now?

It is to me, i'm looking for agreements about the kinds of the refinements
to make is all.

http://codereview.chromium.org/3108042/diff/72001/73029
File webkit/blob/blob_data.cc (right):

http://codereview.chromium.org/3108042/diff/72001/73029#newcode37
webkit/blob/blob_data.cc:37: AppendData(item.data);
is it ok to ignore offset and length here, just checking?

http://codereview.chromium.org/3108042/diff/72001/73031
File webkit/blob/blob_storage_controller.cc (right):

http://codereview.chromium.org/3108042/diff/72001/73031#newcode74
webkit/blob/blob_storage_controller.cc:74:
target_blob_data->AppendData(iter->data());
is it ok to ignore offset and length here?

http://codereview.chromium.org/3108042/diff/72001/73031#newcode84
webkit/blob/blob_storage_controller.cc:84: blob_map_[iter->blob_url().spec()];
Same drill... i think you can use GetBlobData and raw ptrs here too to avoid the
possibility of adding entries and a little refcount churn

http://codereview.chromium.org/3108042/diff/72001/73031#newcode102
webkit/blob/blob_storage_controller.cc:102: if (!blob_data)
Is this expected to have the 'src' blob go missing?

When we get nonsense inputs from child processes, in many cases terminate the
process. Not sure if this type of error is expected or not, if not, is it reason
to kill the child process?

http://codereview.chromium.org/3108042/diff/72001/73031#newcode114
webkit/blob/blob_storage_controller.cc:114: NULL : blob_map_[url.spec()].get();
    How about the following to do the map lookup only once.

    BlobMap::iterator found = blob_map_.find(url.spec());
    return (found != blob_map_.end()) ? found->second : NULL;

http://codereview.chromium.org/3108042/diff/72001/73033
File webkit/blob/blob_storage_controller_unittest.cc (right):

http://codereview.chromium.org/3108042/diff/72001/73033#newcode61
webkit/blob/blob_storage_controller_unittest.cc:61: EXPECT_TRUE(*blob_data_found
== *canonicalized_blob_data2);
does EXPECT_EQ work here?

http://codereview.chromium.org/3108042/diff/72001/73033#newcode69
webkit/blob/blob_storage_controller_unittest.cc:69: EXPECT_TRUE(*blob_data_found
== *blob_data1);
EXPECT_EQ?

http://codereview.chromium.org/3108042/diff/72001/73033#newcode77
webkit/blob/blob_storage_controller_unittest.cc:77: EXPECT_FALSE(blob_data_found
!= NULL);
Maybe switch the expectation around for readability
EXPECT_TRUE(!blob_data_found);

http://codereview.chromium.org/3108042/diff/72001/73033#newcode82
webkit/blob/blob_storage_controller_unittest.cc:82: EXPECT_FALSE(blob_data_found
!= NULL);
EXPECT_TRUE(!blob_data_found);

[jianli, 2010-08-27 18:30:05]

http://codereview.chromium.org/3108042/diff/72001/73018
File chrome/common/render_messages_internal.h (right):

http://codereview.chromium.org/3108042/diff/72001/73018#newcode2719
chrome/common/render_messages_internal.h:2719:
scoped_refptr<webkit_blob::BlobData> /* blob_data */)
On 2010/08/27 07:27:30, darin wrote:
> did you try forward declaring BlobData?

Done.

http://codereview.chromium.org/3108042/diff/72001/73028
File net/base/upload_data.h (right):

http://codereview.chromium.org/3108042/diff/72001/73028#newcode80
net/base/upload_data.h:80: // to define another structure to represent
WebCore::FormData.
On 2010/08/27 07:27:30, darin wrote:
> nit: maybe i should have said WebKit::WebHTTPBody, sorry.  best not to refer
to
> WebCore'isms from Chromium since the comment can bit-rot more easily.

Done.

http://codereview.chromium.org/3108042/diff/72001/73029
File webkit/blob/blob_data.cc (right):

http://codereview.chromium.org/3108042/diff/72001/73029#newcode21
webkit/blob/blob_data.cc:21: // We have to work around this problem here.
On 2010/08/27 07:27:30, darin wrote:
> this seems a bit unfortunate to me.  there should be some better solution. 
> surely, this is not the only piece of code to ever care about preserving 0.

Yes, I agree. I've already sent a patch to davemoore for review:
http://codereview.chromium.org/3175044/show. But unfortunately, there're some
discussions going on. I will use this as a temporary around. If the real fix or
other better fix can be used, I will update this code.

http://codereview.chromium.org/3108042/diff/72001/73029#newcode26
webkit/blob/blob_data.cc:26: };
On 2010/08/27 07:27:30, darin wrote:
> nit: no ';' here
> 
> also, i'd put the anonymous namespace within the webkit_blob namespace.

Done.

[jianli, 2010-08-27 22:47:00]

I addressed all remaining feedbacks in my next patch:
http://codereview.chromium.org/3282003/show. Thanks.

http://codereview.chromium.org/3108042/diff/72001/73029
File webkit/blob/blob_data.cc (right):

http://codereview.chromium.org/3108042/diff/72001/73029#newcode37
webkit/blob/blob_data.cc:37: AppendData(item.data);
On 2010/08/27 18:24:44, michaeln wrote:
> is it ok to ignore offset and length here, just checking?

Yes, it is OK to ignore. Added comment and check.

http://codereview.chromium.org/3108042/diff/72001/73031
File webkit/blob/blob_storage_controller.cc (right):

http://codereview.chromium.org/3108042/diff/72001/73031#newcode74
webkit/blob/blob_storage_controller.cc:74:
target_blob_data->AppendData(iter->data());
On 2010/08/27 18:24:44, michaeln wrote:
> is it ok to ignore offset and length here?

Added comment and check.

http://codereview.chromium.org/3108042/diff/72001/73031#newcode84
webkit/blob/blob_storage_controller.cc:84: blob_map_[iter->blob_url().spec()];
On 2010/08/27 18:24:44, michaeln wrote:
> Same drill... i think you can use GetBlobData and raw ptrs here too to avoid
the
> possibility of adding entries and a little refcount churn

Done.

http://codereview.chromium.org/3108042/diff/72001/73031#newcode102
webkit/blob/blob_storage_controller.cc:102: if (!blob_data)
On 2010/08/27 18:24:44, michaeln wrote:
> Is this expected to have the 'src' blob go missing?
> 
> When we get nonsense inputs from child processes, in many cases terminate the
> process. Not sure if this type of error is expected or not, if not, is it
reason
> to kill the child process?

For now, we assume it is OK to receive this.

http://codereview.chromium.org/3108042/diff/72001/73031#newcode114
webkit/blob/blob_storage_controller.cc:114: NULL : blob_map_[url.spec()].get();
On 2010/08/27 18:24:44, michaeln wrote:
>     How about the following to do the map lookup only once.
> 
>     BlobMap::iterator found = blob_map_.find(url.spec());
>     return (found != blob_map_.end()) ? found->second : NULL;
> 

Done.

http://codereview.chromium.org/3108042/diff/72001/73033
File webkit/blob/blob_storage_controller_unittest.cc (right):

http://codereview.chromium.org/3108042/diff/72001/73033#newcode61
webkit/blob/blob_storage_controller_unittest.cc:61: EXPECT_TRUE(*blob_data_found
== *canonicalized_blob_data2);
On 2010/08/27 18:24:44, michaeln wrote:
> does EXPECT_EQ work here?

No, it does not work because we do not implement operator<<.

http://codereview.chromium.org/3108042/diff/72001/73033#newcode69
webkit/blob/blob_storage_controller_unittest.cc:69: EXPECT_TRUE(*blob_data_found
== *blob_data1);
On 2010/08/27 18:24:44, michaeln wrote:
> EXPECT_EQ?

No, it does not work because we do not implement operator<<.

http://codereview.chromium.org/3108042/diff/72001/73033#newcode77
webkit/blob/blob_storage_controller_unittest.cc:77: EXPECT_FALSE(blob_data_found
!= NULL);
On 2010/08/27 18:24:44, michaeln wrote:
> Maybe switch the expectation around for readability
> EXPECT_TRUE(!blob_data_found);

Done.

http://codereview.chromium.org/3108042/diff/72001/73033#newcode82
webkit/blob/blob_storage_controller_unittest.cc:82: EXPECT_FALSE(blob_data_found
!= NULL);
On 2010/08/27 18:24:44, michaeln wrote:
> EXPECT_TRUE(!blob_data_found);

Done.

[jianli, 2010-08-28 21:05:34]

Updated the patch to use "#if 0/#endif" to temporarily disable
BlobStorageController usages in test_shell. This is because we need to change
WebKit.gyp to include blob dependency and pull it downstream. To expedite the
process, I use this as workaround so that I can land this patch first.

[darin (slow to review), 2010-08-29 21:42:13]

OK

On Sat, Aug 28, 2010 at 2:05 PM, <[email protected]> wrote:

> Updated the patch to use "#if 0/#endif" to temporarily disable
> BlobStorageController usages in test_shell. This is because we need to
> change
> WebKit.gyp to include blob dependency and pull it downstream. To expedite
> the
> process, I use this as workaround so that I can land this patch first.
>
>
> http://codereview.chromium.org/3108042/show
>