Obtaining pointer to member object of a Dictionary

[Henrik Boström]

Hi,

I'm working on webrtc and I'm new to blink, hope this is an appropriate place to ask questions.

TL;DR: I have a Dictionary that should contain a "sequence<RTCCertificate> certificates" and I want to obtain RTCCertificate* pointers to these certificate objects.

Details:

I have a dictionary called RTCConfiguration which has a set of expected member variables according to webrtc standards. I'm trying to add a new member to it. This dictionary has not been defined as a type with an .idl file (not sure why) but is passed to the javascript function as a general Dictionary object which is parsed using DictionaryHelper::get to read out its members.

The new member of RTCConfiguration that I'm adding is "sequence<RTCCertificate> certificates" (RTCCertificate being a new interface that I've added and defined in .idl).

- My question is how do I obtain pointers to these RTCCertificate objects? If I have a Dictionary rtcConfiguration.

The existing code does something similar to read out another member variable, "sequence<RTCIceServer> iceServers". It roughly does this:

ArrayValue iceServers;
DictionaryHelper::get(rtcConfiguration, "iceServers", iceServers);
for (size_t i = 0; ...) {
   Dictionary iceServer;
   iceServers.get(i, iceServer);
   /* Proceeds to parse the member variables of iceServer */
}

But for me it is not enough to parse out the member variables of the RTCCertificate objects. I want pointers to the actual certificate objects that rtcConfiguration.certificates references, I don't want to create new RTCCertificate objects upon parsing.

I looked at Dictionary::get(const String&, v8::Local<v8::Value>&). This should contain a pointer to the member object?

But I'm not sure how to do the casting to get the RTCCertificate*. (And if I end up trying to cast something that isn't an RTCCertificate I need to know about it so that I can cause a javascript invalid argument related exception.)

Any help is appreciated, thanks!

Henrik

[Daniel Cheng]

I didn't test it, but:

bool Dictionary::getKey(const String& key, v8::Local<v8::Value>& value) const;

should get a v8::Value from the Dictionary.

From there, assuming RTCCertificate has an IDL, V8RTCCertificate::toImplWithTypeCheck should turn it from a v8::Value into a RTCCertificate.

Out of curiosity... why doesn't RTCConfiguration have an IDL? It seems like it'd be better to let the bindings generator handle this sort of thing.

Daniel

[Jeremy Roman]

On Mon, Jul 6, 2015 at 1:02 PM, Daniel Cheng <dch...@chromium.org> wrote:

I didn't test it, but:

bool Dictionary::getKey(const String& key, v8::Local<v8::Value>& value) const;

should get a v8::Value from the Dictionary.

From there, assuming RTCCertificate has an IDL, V8RTCCertificate::toImplWithTypeCheck should turn it from a v8::Value into a RTCCertificate.

Out of curiosity... why doesn't RTCConfiguration have an IDL? It seems like it'd be better to let the bindings generator handle this sort of thing.

I'm not on WebRTC, but it looks like RTCConfiguration (2012 or earlier) predates our bindings generator supporting dictionary types (https://chromium.googlesource.com/chromium/blink/+/1790e5a0bc82f4816bbd83aff7cc9d6633ded032, 2014). Maybe, as often happens, nobody got around to moving some dictionary types over to the generator.

[Philip Jägenstedt]

Simply adding RTCConfiguration.idl seems like the best path forward, as Daniel suggests. Trying to handle the conversion of arbitrary values to a DOMString (peerIdentity) and sequence<RTCCertificate> (certificates) with custom code seems tedious and error prone.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Henrik Boström]

Thanks for your responses :)

I agree RTCConfiguration.idl would be a nice cleanup, and RTCConfiguration predating dictionary type support in IDL sounds like a plausable explanation as to why it does not have an IDL file. I don't see any reason for preferring Dictionary over RTCConfiguration.idl myself. I take it the set of all js dictionaries that would have been accepted by a Dictionary parser manually making sure all the variables are valid is the same as the set of all js dictionaries that would be accepted given a correct RTCConfiguration.idl file? Only difference being parsing manually is more of a hassle and more error prone?

I may likely take it upon myself to do this cleanup.

But as for the immediate issue which is blocking higher priority stuff I want to take the path of least resistance. Thanks to the feedback I came up with the following, which seems to do the trick:

ArrayValue certificates;
if (DictionaryHelper::get(rtcConfiguration, "certificates", certificates) &&
    !certificates.isUndefinedOrNull()) {
  size_t numCertificates;
  certificates.length(numCertificates);
  for (size_t i = 0; i < numCertificates; ++i) {
    Dictionary dictCert;
    certificates.get(i, dictCert);

    RTCCertificate* certificate = nullptr;
    v8::Local<v8::Value> valCert = dictCert.v8Value();
    if (!valCert.IsEmpty()) {
      certificate = V8RTCCertificate::toImplWithTypeCheck(scriptState->isolate(), valCert);
    }
    /* certificate != null only if it is an RTCCertificate */
  }
}

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

On Tue, Jul 7, 2015 at 11:31 AM, Henrik Boström <hb...@chromium.org> wrote:

Thanks for your responses :)

I agree RTCConfiguration.idl would be a nice cleanup, and RTCConfiguration predating dictionary type support in IDL sounds like a plausable explanation as to why it does not have an IDL file. I don't see any reason for preferring Dictionary over RTCConfiguration.idl myself. I take it the set of all js dictionaries that would have been accepted by a Dictionary parser manually making sure all the variables are valid is the same as the set of all js dictionaries that would be accepted given a correct RTCConfiguration.idl file? Only difference being parsing manually is more of a hassle and more error prone?

Yes, it should be a simple conversion, although RTCConfiguration and friends are more complex than most dictionaries so if you stumble upon any problems just ask. One nice thing about dictionaries is that when the members have defaults, you can skip the hasFoo() checks and just use the value, offloading the boring bits to the generated code. It's also pretty likely that there's at least some small spec violation in the manual code that you'd uncover and fix.

Philip