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

[Loïc Yhuel]

Hello Ciao,

Le 12/10/2011 01:26, Caio Marcelo de Oliveira Filho a écrit :
> 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.
You speak about sending object information to the web page JS, so it can 
dynamically create a JS object.
My idea was similar, but with everything constructed on WebView side, so 
the web page only has to evaluate what it receives to create an object 
with property getters, wrapper functions sending messages to call 
Q_INVOKABLE methods or emit signals on native side. But obviously your 
solution is easier, as soon as we can use the WebScripts interface to 
send the whole "object information parser" code in a js file.

>
> 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.
In some cases, the best optimization would be to implement everything in 
the web process.
You don't need the WebView if for example you want to expose D-Bus 
services using QtDbus.
If synchronous calls are possible in this case, it will be even better, 
as it would need less modifications to existing code.

>
> Cheers,
>