Extra KDE Telepathy modules moving to Extragear

[Albert Astals Cid]

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.

Albert

> 
> David Edmundon