[webkit-qt] API proposal for handling (some) hybrid use cases

[Caio Marcelo de Oliveira Filho]

Hello Loïc,

Thanks for your questions and comments.


>> I see your examples and prototype code are always using a string as
>> message argument.
>> Is it possible to use a QVariant like with the QtWebKit bridge ?

I had in mind passing strings only. Users would handle serialization
(maybe thru libraries).

QVariant is not a good choice here IMHO because in the typical case
both sides will be talking JS already (at least one of the sides).
JSON.stringfy/parse, and the moral equivalent in Qt C++ would be
enough.


>> If I understand correctly, it won't be possible to implement synchronous
>> JS ->  C++ calls like Q_INVOKABLE methods.

Message exchange would be asynchronous. We can support Q_INVOKABLE if
it's OK to get the answer in a callback, see below.


On Tue, Oct 11, 2011 at 7:32 PM, Loïc Yhuel
<loic.yhuel_ext at softathome.com> wrote:
> How would you wrap a QObject* (so it's signals could be invoked, properties
> accessed) ?

On the WebView side, one could create a wrapper that take QObjects,
and post message warning the other side about the object being tracked
-- including properties and such. This watcher would send messages
when signals are emitted. On the other side (web page JS), when
information about new object is sent, a new object is created with
functions corresponding to slots and to property readings. Due to
asynchronous nature, we won't have the answers immediatly, so those
functions take callbacks. Essentially not very different from how IPC
works for WK2.

Note this is only one way to do it -- I'm not planning to support
QObject integration. But I think any asynchronous way to bridge the
things can be fit in the existing scheme.


> Dynamically constructing wrapper functions, and sending them as JSON would
> be complex, and probably slow.

I don't understand what do you mean by constructing wrapper functions
and send them as JSON. I don't think this is necessary.


Since there are two processes involved, one could try to do is to
optimize for the case of exposing QObjects as much as possible. My
proposal goes on the other direction: let's communicate in another
way.


Cheers,

-- 
Caio Marcelo de Oliveira Filho
OpenBossa - INdT