Bug 25422

(In reply to comment #0)
> <http://git.collabora.co.uk/?p=user/smcv/telepathy-qt4-smcv.git;a=shortlog;h=refs/heads/futuristic>
> generates code for the Call draft API from telepathy-spec 0.19.0. This code is
> hidden (not part of the API or ABI), but can be used by StreamedMediaChannel to
> interoperate with Call implementations.
> 
> It also adds telepathy-glib service-side code generation, which will become
> necessary when the Call CM from Bug #25416 arrives and is used by regression
> tests.
> 

The only thing I didn't like is calling TpFuture::registerTypes from inside streamed-media-channel.cpp. I believe the call should be placed somewhere inside registerTypes. Also I would change the namespace to Tp::Future instead of TpFuture, so using namespace Tp; works

(In reply to comment #1)
> The only thing I didn't like is calling TpFuture::registerTypes from inside
> streamed-media-channel.cpp. I believe the call should be placed somewhere
> inside registerTypes.

Two objections to that:

* it's an implementation detail of StreamedMediaChannel; none of these types are meant to be public API

* Tp::registerTypes is generated code, so it's difficult to modify case-by-case :-)

I wouldn't object to renaming the generated function to _registerTypes and making it unconditionally TELEPATHY_QT4_NO_EXPORT, then adding a handwritten Tp::registerTypes() that just calls Tp::_registerTypes and TpFuture::_registerTypes?

> Also I would change the namespace to Tp::Future instead
> of TpFuture, so using namespace Tp; works

So you can use Future::ChannelTypeCallInterface? I don't really see the value, but if you'd prefer to type :: more often, I suppose I could :-)

(In reply to comment #2)
> (In reply to comment #1)
> > The only thing I didn't like is calling TpFuture::registerTypes from inside
> > streamed-media-channel.cpp. I believe the call should be placed somewhere
> > inside registerTypes.
> 
> Two objections to that:
> 
> * it's an implementation detail of StreamedMediaChannel; none of these types
> are meant to be public API
> 
> * Tp::registerTypes is generated code, so it's difficult to modify case-by-case
> :-)
> 
> I wouldn't object to renaming the generated function to _registerTypes and
> making it unconditionally TELEPATHY_QT4_NO_EXPORT, then adding a handwritten
> Tp::registerTypes() that just calls Tp::_registerTypes and
> TpFuture::_registerTypes?
I like that, I would go this route

> 
> > Also I would change the namespace to Tp::Future instead
> > of TpFuture, so using namespace Tp; works
> 
> So you can use Future::ChannelTypeCallInterface? I don't really see the value,
> but if you'd prefer to type :: more often, I suppose I could :-)
> 
Please, our namespace is Tp so anything in tp-qt4 should be using Tp as the main namespace IMHO. Tp::Future, Tp::Client, Tp::Server, ...

(In reply to comment #2)
> I wouldn't object to renaming the generated function to _registerTypes and
> making it unconditionally TELEPATHY_QT4_NO_EXPORT, then adding a handwritten
> Tp::registerTypes() that just calls Tp::_registerTypes and
> TpFuture::_registerTypes?

I've done this on my branch, please re-review.

> > Also I would change the namespace to Tp::Future instead
> > of TpFuture, so using namespace Tp; works

I think we agreed on IRC that TpFuture was, in fact, appropriate, since the generated future code is not part of the library API or ABI (that's the whole point), so I haven't changed this.

Andre, could you review/merge this please? I hear you have a branch or two that depends on it :-P

(In reply to comment #5)
> Andre, could you review/merge this please? I hear you have a branch or two that
> depends on it :-P
> 

Actually I am using it for Call/Conference support. I will merge it when I merge the Call branch

Merged upstream. It will be included in next version 0.3.0