Extra KDE Telepathy modules moving to Extragear

[David Edmundson]

On Sun, Jun 3, 2012 at 10:45 PM, Albert Astals Cid <aacid at kde.org> wrote:
> El Dijous, 31 de maig de 2012, a les 20:10:08, David Edmundson va escriure:
>> 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?
>
> Yes, my mail about SearchHit struct and  weird \ in pending-search.h seems to
> have been ignored.
>
Forgotten rather than ignored. Not that that's much of an excuse.

Fixed now.
Thanks.

> Albert
>
>>
>> David Edmundon