[PPAPI] Added PP_VARTYPE_RESOURCE as a PP_VarType enum value.

ppapi/proxy/raw_var_data.cc

Index: ppapi/proxy/raw_var_data.cc
diff --git a/ppapi/proxy/raw_var_data.cc b/ppapi/proxy/raw_var_data.cc
index a550c3fca052892976c32288a6b807fa4cff211f..409345d0b9521bf0cd0d18d341dcc265731aea54 100644
--- a/ppapi/proxy/raw_var_data.cc
+++ b/ppapi/proxy/raw_var_data.cc
@@ -240,6 +240,13 @@ RawVarData* RawVarData::Create(PP_VarType type) {
       return new ArrayRawVarData();
     case PP_VARTYPE_DICTIONARY:
       return new DictionaryRawVarData();
+    case PP_VARTYPE_RESOURCE:
+      // TODO(mgiuca): Add ResourceRawVarData.
+      // This path will be reached if a NaCl module attempts to pass a
+      // PP_VARTYPE_RESOURCE in a message.
+      NOTIMPLEMENTED();
+      CHECK(false) << "Serializing PP_VARTYPE_RESOURCE is not supported.";

[Matt Giuca, 2013/09/03 08:32:22]

I agonized about whether to check-fail here or have a more graceful error (e.g.,
log error and cancel the message post). I could do the latter, but it requires
some refactoring so it's probably not worth it for a temporary change.

However, there is an ongoing discussion with Yuzhu about how to deal with
resources we can't convert to V8 values (later on), and if we are going to make
it cancel sending the whole message, then we may as well do the refactor here.

I'd be interested in whether you think this checkfail is OK for a temporary
solution.

[dmichael (off chromium), 2013/09/03 16:25:17]

The strategy I think we were going to use for other failures in serialization
(where it's not easy to bubble up an error to the sender) is to create an
"Invalid" SerializedVar. The receiving end can then decide what to do when it
gets an invalid var. In Messaging, we just drop it and maybe log. You'd have to
go to all the call sites for Create() and make sure the NULL bubbles up right
(it looks like it doesn't right now).

I think it might be worth doing that...  in case the resource var is not all
done in 31. WDYT?

[yzshen1, 2013/09/03 20:19:53]

WRT our discussion, I personally prefer not to give an incomplete message to JS
when failure occurs. If we send some resource to the renderer side and find out
that it cannot be converted to V8 value. We could drop the message at that point
(and log errors). We don't have to make all decisions at the plugin side.

[dmichael (off chromium), 2013/09/03 20:39:41]

I agree; I think we're suggesting the same thing :). We can make an invalid
serialized var:
https://code.google.com/p/chromium/codesearch#chromium/src/ppapi/proxy/ppb_in...
And the Messaging proxy should do the right thing already.

[Matt Giuca, 2013/09/10 01:17:13]

So this is a lot more temporary than I let on. I have another CL almost ready to
go, that adds ResourceRawVarData, which will remove this NOTIMPLEMENTED(). That
should definitely be in M31 even if the rest of resource var handling is not.

After that CL, if someone tries to pass a ResourceRawVarData from JS to NaCl, it
will successfully pass it through to the renderer and hit v8_var_converter (and
I'll have to write logic in there to make it fail to produce a V8 value).

Therefore, I don't think it is worth making this not checkfail here. However,
beause I'm in a hurry, I did implement it in Patch Set 8. I'd prefer to submit
Patch Set 7, so please review that. But if you want it to fail gracefully
instead of checkfailing in this CL, please look at Patch Set 8.

+      return NULL;
   }
   NOTREACHED();
   return NULL;