Extra KDE Telepathy modules moving to Extragear

[David Edmundson]

On Mon, Apr 30, 2012 at 11:28 PM, David Edmundson
<david at davidedmundson.co.uk> wrote:
> On Sun, Apr 29, 2012 at 2:42 PM, Kevin Krammer <krammer at kde.org> wrote:
>> On Sunday, 2012-04-29, Martin Klapetek wrote:
>>> On Sat, Apr 28, 2012 at 22:44, Kevin Krammer <krammer at kde.org> wrote:
>>> > On Saturday, 2012-04-28, George Kiagiadakis wrote:
>>> > > No, the classes that wrap GObjects do not need a d-pointer. All the
>>> > > calls are forwarded to the underlying GObject and if for any reason we
>>> > > ever need to save extra data on the wrapper class (which is highly
>>> > > unlikely), we should use the GObject qdata for that. Wrapper classes
>>> > > may be destroyed and re-allocated by QtGLib and therefore they
>>> > > shouldn't hold any data.
>>> >
>>> > So the GObject has a d-pointer?
>>> >
>>> > Any specific reason there is a GObject at all? My very basic
>>> > understanding of
>>> > Telepathy was that it is D-Bus based services.
>>>
>>> Telepathy is based on D-Bus services, however this is about Telepathy
>>> logger [1], which is a GObject-based implementation of a central logging
>>> Telepathy component, which does not use D-Bus for sending the logs as it is
>>> quite heavy data and D-Bus for this purpose is rather slow, so it provides
>>> a direct access API.
>>
>> The documentation you linked to seems to be quite of of date (most of the
>> links in it don't work), so I would still need some clarifications.
>>
>> The document claims that the logger is an independent service, i.e. it says:
>> "Telepathy Logger is a session daemon".
>>
>> I quite don''t understand the term direct access API in the context of a
>> daemon.
>>
>> Usually daemon refers to a separate process. Communicating with a process is
>> to my best understanding never done by linking the daemon code into the client
>> applications.
>>
> Yes, starts whilst you're chatting. Closes when you're done.
>>
>> My best guess so far is that there is some library that provides read-only
>> access to files the independent logger writes onto disk.
>>
>
> Your guess is effectively correct. Telepathy-logger is a bit more
> complex as it writes to and reads from multiple backends.
> XML files or SQLite and it also reads (read only) Pidgin log files as
> their way of importing old log files.
>
>>> Our telepathy-logger-qt, which we want to move to
>>> Extragear, basically just wraps the original logger into Qt-like API, so
>>> that it can be used with Qt/KDE apps easily.
>>
>> Based on my guess I would strongly recommend to put the wrapped GObject into
>> the wrapper's d-pointer. Otherwise your only way of ever implementing that
>> natively is to name a struct GObject and use that as the native
>> implementation's d-pointer, making it very hard for any using application to
>> link with any library exposing GObject symbols.
>>
> If we ever implemented it natively I would make so many other changes
> to the API that I would bump the major version number and not even try
> to keep compatibility.
>
>> Cheers,
>> Kevin
>>
>>> [1] - http://telepathy.freedesktop.org/wiki/Logger
>>
>> --
>> Kevin Krammer, KDE developer, xdg-utils developer
>> KDE user support, developer mentoring


*bump*

So to summarise so far:
There were some issues with call-ui which are now all fixed.
There were also comments about gobjects in the telepathy-logger and
d-pointers which I disagree with and have hopefully explained my
rationale.

Are there any further objections to moving these forward into extragear?

David Edmundon