dbus-cplusplus-devel — Internal development and usage of the dbus-c++ API

Re: [dbus-cplusplus-devel] Server and closing connections (corrected patch, sorry)

[Ignacy G. <sf...@qu...>]

It's a bit late I guess...

Here comes the patch that actually should work.

-- 
To err is human, to purr feline.

Re: [dbus-cplusplus-devel] Server and closing connections (patch)

[Ignacy G. <sf...@qu...>]

On Thu, Sep 04, 2008 at 10:37:40PM +0200, thus spake Ignacy Gawedzki:
> On Thu, Sep 04, 2008 at 08:55:36PM +0200, thus spake P. Durante:
> > since the private data is in a reference counted smart pointer
> > (Connection::_pvt), delete is called automatically when the last
> > Connection referring to that Private data is deallocated
> 
> You know that's funny, because I was about to suggest the use of a smart
> pointer, to do just that.  I've totally overlooked that it was already a smart
> pointer. =)  Sorry for the bother then, my bad.

Back to the original issue: here's a patch.

What this does is basically add a sort of "bound callback" to each connection
that is filled during Server::on_new_conn_cb() and provides everything but the
Connection::Private pointer for Connection::Private::do_dispatch() to call.

The idea is to make the server handle the fact that the connection is
disconnected.  First "privately" in Server::Private::on_rem_connection() which
in turn calls Server::on_rem_connection() using the pointer to the Server's
instance that has been bounded in the callback.  By the way, is there any good
reason for Callback::_cb not to be a reference instead of a pointer?

I've also added specialisations in util.h for the case a callback doesn't need
any argument.  I wrote this for an earlier version that's been changed since,
but I decided to leave it there so it won't harm.

One last question: wouldn't it be better to avoid linear search during
detach_server()?  An iterator to the added list element could be kept
somewhere in Connection::Private and could be used by
Server::Private::on_rem_connection() to remove the element in O(1).

Please tell me what you think.

Ignacy

-- 
-= Best Viewed Using [INLINE] =-

Re: [dbus-cplusplus-devel] Server and closing connections

[Ignacy G. <sf...@qu...>]

On Thu, Sep 04, 2008 at 08:55:36PM +0200, thus spake P. Durante:
> On Thu, Sep 4, 2008 at 8:08 PM, Ignacy Gawedzki <sf...@qu...> wrote:
> > Uuuh, if you mean evidence for Connection::Private instances not being freed,
> > yes.  They are new'd in Connection::Connection(const char*, bool) but I see no
> > corresponding delete anywhere in the sources.
> >
> since the private data is in a reference counted smart pointer
> (Connection::_pvt), delete is called automatically when the last
> Connection referring to that Private data is deallocated

You know that's funny, because I was about to suggest the use of a smart
pointer, to do just that.  I've totally overlooked that it was already a smart
pointer. =)  Sorry for the bother then, my bad.

-- 
To err is human, to purr feline.

Re: [dbus-cplusplus-devel] Server and closing connections

[P. D. <sh...@gm...>]

On Thu, Sep 4, 2008 at 8:08 PM, Ignacy Gawedzki <sf...@qu...> wrote:
> On Thu, Sep 04, 2008 at 05:59:18PM +0200, thus spake P. Durante:
>> On Thu, Sep 4, 2008 at 5:42 PM, Ignacy Gawedzki <sf...@qu...> wrote:
>> > It seems there are more serious issues with the lifetime management of
>> > Connection::Private instances, which are created but never freed it seems.
>> > Before I can go further with my initial problems, I must resolve these.
>> >
>> do you have any evidence? dbus_connection_unref is called in the
>> destructor for this very reason, and calls to ref/unref are balanced
>> so to keep the Connection::Private (and the internal DBusConnection)
>> around for as long as there's at least a DBus::Connection referring to
>> it
>
> Uuuh, if you mean evidence for Connection::Private instances not being freed,
> yes.  They are new'd in Connection::Connection(const char*, bool) but I see no
> corresponding delete anywhere in the sources.
>
since the private data is in a reference counted smart pointer
(Connection::_pvt), delete is called automatically when the last
Connection referring to that Private data is deallocated

Re: [dbus-cplusplus-devel] Server and closing connections

[Ignacy G. <sf...@qu...>]

On Thu, Sep 04, 2008 at 05:59:18PM +0200, thus spake P. Durante:
> On Thu, Sep 4, 2008 at 5:42 PM, Ignacy Gawedzki <sf...@qu...> wrote:
> > It seems there are more serious issues with the lifetime management of
> > Connection::Private instances, which are created but never freed it seems.
> > Before I can go further with my initial problems, I must resolve these.
> >
> do you have any evidence? dbus_connection_unref is called in the
> destructor for this very reason, and calls to ref/unref are balanced
> so to keep the Connection::Private (and the internal DBusConnection)
> around for as long as there's at least a DBus::Connection referring to
> it

Uuuh, if you mean evidence for Connection::Private instances not being freed,
yes.  They are new'd in Connection::Connection(const char*, bool) but I see no
corresponding delete anywhere in the sources.

-- 
-= Best Viewed Using [INLINE] =-

Re: [dbus-cplusplus-devel] Server and closing connections

[P. D. <sh...@gm...>]

On Thu, Sep 4, 2008 at 5:42 PM, Ignacy Gawedzki <sf...@qu...> wrote:
> On Thu, Sep 04, 2008 at 12:17:42AM +0200, thus spake P. Durante:
>> Hi,
>>
>> On Wed, Sep 3, 2008 at 10:50 PM, Ignacy Gawedzki <sf...@qu...> wrote:
>> > Hi,
>> >
>> > I'm playing with dbus-c++ for two days now and I stumbled upon a particular
>> > problem related to using DBus::Server.
>> >
>> > It seems that this part of the code needs some work and that most of the
>> > people simply don't care, since, please correct me if I'm wrong, it's used
>> > only in peer-to-peer communications (i.e. not going through dbus-daemon).
>> >
>> to be honest, as far as I know, it's not used at all
>>
>> > Of course I could for now go along with using dbus-daemon and not care about
>> > DBus::Server that much, but I'm still wondering how to make that thing work
>> > right.
>> >
>> > A major problem with DBus::Server is the way DBus::Connection objects are
>> > dealt with and more generally the fact that there apparently is no clean way
>> > of cleaning up stuff on client disconnection.  As for DBus::Connection
>> > instances, they obviously are never removed from the
>> > DBus::Server::Private::connections list.
>> >
>> right
>>
>> > The thing is that after looking into the libdbus API and having searched
>> > through the mailing list archives, it seems to me that there is a deeper
>> > problem with detecting client disconnections.  A watch does not hold any
>> > reference to the connection it's associated with and relying on connections
>> > (and also watches) to have an associated file descriptor (that might be used
>> > to match the one with the other) is not a good way to go, according to the API
>> > docs (a connection is not necessarily associated with a file descriptor).  So
>> > at no point is there a way to associate a watch to its connection, so as to
>> > check whether it's still connected after a watch handling, or something like
>> > that.
>> >
>> > Do you see any way of achieving this?
>> >
>> if I understand the question correctly, the internal data pointer
>> which is now used to store the
>> Dispatcher associated with the Watch could be replaced with a pointer
>> to the Connection owning the watch
>> http://dbus.freedesktop.org/doc/dbus/api/html/structDBusWatch.html#ec763277e3fd3a3fbf34ea5bd7dda617
>> (the dispatcher will still be accessible through the connection object)
>>
>> then, a special case to handle a closing connection could be added to
>> DBus::Watch::handle()
>> (checking for POLLHUP|POLLERR)
>>
>> out of curiosity, I've looked at how the Qt people do it but
>> apparently they didn't implement it either
>> http://lists.kde.org/?l=kde-devel&m=120185882521538&w=2
>
> After having looked at that again and more from the libdbus API standpoint, I
> have noticed that in any case the disconnection should be noticed and that in
> fact, in dbus-c++, the Connection::Private::do_dispatch() method does check
> whether the connections is terminated (by a call to
> dbus_connection_get_is_connected()) and calls
> Connection::Private::detach_server() in that case.
>
> It seems there are more serious issues with the lifetime management of
> Connection::Private instances, which are created but never freed it seems.
> Before I can go further with my initial problems, I must resolve these.
>
do you have any evidence? dbus_connection_unref is called in the
destructor for this very reason, and calls to ref/unref are balanced
so to keep the Connection::Private (and the internal DBusConnection)
around for as long as there's at least a DBus::Connection referring to
it

Re: [dbus-cplusplus-devel] Server and closing connections

[Ignacy G. <sf...@qu...>]

On Thu, Sep 04, 2008 at 12:17:42AM +0200, thus spake P. Durante:
> Hi,
> 
> On Wed, Sep 3, 2008 at 10:50 PM, Ignacy Gawedzki <sf...@qu...> wrote:
> > Hi,
> >
> > I'm playing with dbus-c++ for two days now and I stumbled upon a particular
> > problem related to using DBus::Server.
> >
> > It seems that this part of the code needs some work and that most of the
> > people simply don't care, since, please correct me if I'm wrong, it's used
> > only in peer-to-peer communications (i.e. not going through dbus-daemon).
> >
> to be honest, as far as I know, it's not used at all
> 
> > Of course I could for now go along with using dbus-daemon and not care about
> > DBus::Server that much, but I'm still wondering how to make that thing work
> > right.
> >
> > A major problem with DBus::Server is the way DBus::Connection objects are
> > dealt with and more generally the fact that there apparently is no clean way
> > of cleaning up stuff on client disconnection.  As for DBus::Connection
> > instances, they obviously are never removed from the
> > DBus::Server::Private::connections list.
> >
> right
> 
> > The thing is that after looking into the libdbus API and having searched
> > through the mailing list archives, it seems to me that there is a deeper
> > problem with detecting client disconnections.  A watch does not hold any
> > reference to the connection it's associated with and relying on connections
> > (and also watches) to have an associated file descriptor (that might be used
> > to match the one with the other) is not a good way to go, according to the API
> > docs (a connection is not necessarily associated with a file descriptor).  So
> > at no point is there a way to associate a watch to its connection, so as to
> > check whether it's still connected after a watch handling, or something like
> > that.
> >
> > Do you see any way of achieving this?
> >
> if I understand the question correctly, the internal data pointer
> which is now used to store the
> Dispatcher associated with the Watch could be replaced with a pointer
> to the Connection owning the watch
> http://dbus.freedesktop.org/doc/dbus/api/html/structDBusWatch.html#ec763277e3fd3a3fbf34ea5bd7dda617
> (the dispatcher will still be accessible through the connection object)
> 
> then, a special case to handle a closing connection could be added to
> DBus::Watch::handle()
> (checking for POLLHUP|POLLERR)
> 
> out of curiosity, I've looked at how the Qt people do it but
> apparently they didn't implement it either
> http://lists.kde.org/?l=kde-devel&m=120185882521538&w=2

After having looked at that again and more from the libdbus API standpoint, I
have noticed that in any case the disconnection should be noticed and that in
fact, in dbus-c++, the Connection::Private::do_dispatch() method does check
whether the connections is terminated (by a call to
dbus_connection_get_is_connected()) and calls
Connection::Private::detach_server() in that case.

It seems there are more serious issues with the lifetime management of
Connection::Private instances, which are created but never freed it seems.
Before I can go further with my initial problems, I must resolve these.

-- 
 "The whole problem with the world is that fools and fanatics are
   always so certain of themselves, and wiser people so full of doubts."
                                                 - Bertrand Russell

Re: [dbus-cplusplus-devel] Server and closing connections

[P. D. <sh...@gm...>]

Hi,

On Wed, Sep 3, 2008 at 10:50 PM, Ignacy Gawedzki <sf...@qu...> wrote:
> Hi,
>
> I'm playing with dbus-c++ for two days now and I stumbled upon a particular
> problem related to using DBus::Server.
>
> It seems that this part of the code needs some work and that most of the
> people simply don't care, since, please correct me if I'm wrong, it's used
> only in peer-to-peer communications (i.e. not going through dbus-daemon).
>
to be honest, as far as I know, it's not used at all

> Of course I could for now go along with using dbus-daemon and not care about
> DBus::Server that much, but I'm still wondering how to make that thing work
> right.
>
> A major problem with DBus::Server is the way DBus::Connection objects are
> dealt with and more generally the fact that there apparently is no clean way
> of cleaning up stuff on client disconnection.  As for DBus::Connection
> instances, they obviously are never removed from the
> DBus::Server::Private::connections list.
>
right

> The thing is that after looking into the libdbus API and having searched
> through the mailing list archives, it seems to me that there is a deeper
> problem with detecting client disconnections.  A watch does not hold any
> reference to the connection it's associated with and relying on connections
> (and also watches) to have an associated file descriptor (that might be used
> to match the one with the other) is not a good way to go, according to the API
> docs (a connection is not necessarily associated with a file descriptor).  So
> at no point is there a way to associate a watch to its connection, so as to
> check whether it's still connected after a watch handling, or something like
> that.
>
> Do you see any way of achieving this?
>
if I understand the question correctly, the internal data pointer
which is now used to store the
Dispatcher associated with the Watch could be replaced with a pointer
to the Connection owning the watch
http://dbus.freedesktop.org/doc/dbus/api/html/structDBusWatch.html#ec763277e3fd3a3fbf34ea5bd7dda617
(the dispatcher will still be accessible through the connection object)

then, a special case to handle a closing connection could be added to
DBus::Watch::handle()
(checking for POLLHUP|POLLERR)

out of curiosity, I've looked at how the Qt people do it but
apparently they didn't implement it either
http://lists.kde.org/?l=kde-devel&m=120185882521538&w=2

> Ignacy
>
Paolo

[dbus-cplusplus-devel] Server and closing connections

[Ignacy G. <sf...@qu...>]

Hi,

I'm playing with dbus-c++ for two days now and I stumbled upon a particular
problem related to using DBus::Server.

It seems that this part of the code needs some work and that most of the
people simply don't care, since, please correct me if I'm wrong, it's used
only in peer-to-peer communications (i.e. not going through dbus-daemon).

Of course I could for now go along with using dbus-daemon and not care about
DBus::Server that much, but I'm still wondering how to make that thing work
right.

A major problem with DBus::Server is the way DBus::Connection objects are
dealt with and more generally the fact that there apparently is no clean way
of cleaning up stuff on client disconnection.  As for DBus::Connection
instances, they obviously are never removed from the
DBus::Server::Private::connections list.

The thing is that after looking into the libdbus API and having searched
through the mailing list archives, it seems to me that there is a deeper
problem with detecting client disconnections.  A watch does not hold any
reference to the connection it's associated with and relying on connections
(and also watches) to have an associated file descriptor (that might be used
to match the one with the other) is not a good way to go, according to the API
docs (a connection is not necessarily associated with a file descriptor).  So
at no point is there a way to associate a watch to its connection, so as to
check whether it's still connected after a watch handling, or something like
that.

Do you see any way of achieving this?

Ignacy

-- 
/* This is not a comment */

Re: [dbus-cplusplus-devel] Proposal: Give objects through dbus-c++

[Andreas V. <li...@br...>]

Am Tue, 2 Sep 2008 00:20:15 +0200 schrieb Andreas Volz:

> Am Sun, 31 Aug 2008 18:16:13 +0200 schrieb P. Durante:
> 
> Hello Paolo,
> 
> currently I work on a example implementation that explains all my
> ideas. I hope tomorrow it's finished and ready to show. Then we talk
> again about it.

Here is the result of my proposal. I modified the dbusxx-xml2cpp tool
to generate the object binding. See here:

http://gitorious.org/projects/dbus-cplusplus/repos/mainline/blobs/master/tools%2Fxml2cpp.cpp

As result it parses the object="MyObject" code in the XML and generates
code based on it. See here a prototype of my communication library:

http://www.tux-style.de/tmp/dbus-cplusplus/oicf-0.1.tar.gz

and here the dbus-c++ code generated with it:

http://www.tux-style.de/tmp/dbus-cplusplus/oicf-0.1_bin.tar.gz

It seems to work for signals and methods, but it's not extreme tested
for in and out values. I need to write more tests for it.

It works well and is 100% compatible to other dbus bindings. You even
don't need to do it in dbus-c++ if you fear of more object creations
while communications. Simply don't use the "object" tag.

What do you think?

I would like to see it integrated into the official repo.

BTW: As I noticed the tabs aren't perfect. In both source code and
generated code. But I think that's a minor problem.

BTW2: Maybe you noticed that I added some more comments for
dbusxx-xml2cpp while understanding it. So the next new person will
faster understand it.

regards
Andreas

Re: [dbus-cplusplus-devel] Proposal: Give objects through dbus-c++

[Andreas V. <li...@br...>]

Am Sun, 31 Aug 2008 18:16:13 +0200 schrieb P. Durante:

Hello Paolo,

currently I work on a example implementation that explains all my
ideas. I hope tomorrow it's finished and ready to show. Then we talk
again about it.

regards
Andreas

> Hi,
> 
> On Sat, Aug 30, 2008 at 12:24 AM, Andreas Volz <li...@br...>
> wrote:
> > Hello,
> >
> > while writing a DBUS interface for my application I found a way to
> > give objects direct "through" DBUS. In reality the objects aren't
> > give through DBUS. Only the copyable contents are given though DBUS.
> >
> > So how does it work?
> >
> > See the example communication framework here. It's only a prototype
> > and still has some problems.
> >
> > http://tux-style.de/tmp/oicf-0.1.tar.gz
> >
> > Look at OICFControlListener.cpp: (below as reference. Use the
> > source for more overview)
> >
> > class OICFControlListener :
> >  public org::oicf::ControlListener,
> >  public DBus::IntrospectableProxy,
> >  public DBus::ObjectProxy
> > {
> > public:
> >  OICFControlListener ( DBus::Connection& connection, const char*
> > path, const char* name ) : DBus::ObjectProxy (connection, path,
> > name) {}
> >
> >  virtual void onAxisListener (const KeyEvent &event) = 0;
> >  virtual void onButtonListener (const KeyEvent &event) = 0;
> >
> > private:
> >  void onAxisListener(const KeyEvent_Dbus_t &eventAxis)
> >  {
> >    KeyEvent event;
> >    event << eventAxis;
> >
> >    onAxisListener (event);
> >  }
> >
> >  void onButtonListener(const KeyEvent_Dbus_t &eventButton)
> >  {
> >    KeyEvent event;
> >    event << eventButton;
> >
> >    onButtonListener (event);
> >  }
> >
> > };
> >
> > As you see the private onAxisListener() from dbus-c++ is
> > overwritten and creates the object KeyEvent, fills it with the '<<'
> > operator and calls the new public callback function.
> >
> > Look into KeyEvent.h:
> 
> I've perused the archive but can't find this file
> 
> >
> > typedef ::DBus::Struct <int32_t, int16_t, uint8_t, bool>
> > KeyEvent_Dbus_t;
> >
> > class KeyEvent
> > {
> > public:
> > ...
> >
> > public:
> >  int32_t time;
> >  int16_t value;
> >  int8_t number;
> >
> > public:
> >  void operator << (const KeyEvent_Dbus_t& event)
> >  {
> >    time = event._1;
> >    value = event._2;
> >    number = event._3;
> >  }
> > };
> >
> 
> from what I've read you basically want to automate marshaling and
> unmarshaling of DBus structured types, is that correct?
> if this where to be done in the code generator, where would the field
> names (in this case, "time", "value", "number") be stored? in the xml?
> 
> > This works as long as '<<' and '>>' operator is implemented correct
> > in the class you like to give "through" dbus-c++. (See
> > CoordWGS84.h) for another example.
> >
> 
> this file can't be found either :-\
> 
> > For sure objects are not given through DBUS, but it looks and
> > behaves for the user in that way.
> >
> > Look at the introspection XML:
> >
> > <?xml version="1.0" ?>
> > <node name="/org/oicf/ControlListener">
> >  <interface name="org.oicf.ControlListener">
> >
> >    <signal name="onAxisListener">
> >      <arg type="(inyb)" name="eventAxis" direction="out"/>
> >    </signal>
> >
> >    <signal name="onButtonListener">
> >      <arg type="(inyb)" name="eventButton" direction="out"/>
> >    </signal>
> >
> >  </interface>
> >
> > </node>
> >
> > You see that it has a struct that exactly fits the KeyEvent.h data.
> >
> > This works so far, but it's much way to write all that wrapper
> > functions on my own. This is exact the work a code generator is
> > done for. I would propose to change the XML format in that way:
> >
> > <?xml version="1.0" ?>
> > <node name="/org/oicf/ControlListener">
> >  <interface name="org.oicf.ControlListener">
> >
> >    <signal name="onAxisListener">
> >      <arg type="(inyb)" name="eventAxis" direction="out"
> > object="KeyEvent"/> </signal>
> >
> >    <signal name="onButtonListener">
> >      <arg type="(inyb)" name="eventButton" direction="out"
> > object="KeyEvent"/> </signal>
> >
> >  </interface>
> >
> > </node>
> >
> >
> > So the code generator know that he should add some code to give
> > "class KeyEvent" in a "KeyEvent.h" in dbus-c++ as shown above. The
> > only thing that has to be hand written is the KeyEvent.h and the
> > '<<' and '>>' operator.
> >
> > This proposal is backwards compatible as other DBUS implementations
> > simply ignore the "object" tag and give access to the data with the
> > normal DBUS mechanisms.
> >
> 
> XML interfaces are supposed to be distributed to allow interoperation
> with other applications and/or languages, since this addition would be
> very specific to this particular implementation it could be
> implemented using a dedicated annotation, other languages and bindings
> (Glib and Qt come to mind) already do it, see
> 
> http://dbus.freedesktop.org/doc/dbus-specification.html
> 
> and look for "annotations"
> 
> > What do you think about this idea?
> >
> 
> from what I understand you basically want to implement CORBA
> ValueTypes in DBus :-)
> 
> > regards
> > Andreas
> >
> 
> regards,
> Paolo
> 

Re: [dbus-cplusplus-devel] #define problem in dispatcher.h/.cpp

[P. D. <sh...@gm...>]

> Hello,
>
> there's still a problem in dispatcher.h.
>
> #ifndef DBUS_HAS_RECURSIVE_MUTEX
> typedef Mutex *(*MutexNewFn)();
> typedef bool (*MutexFreeFn)(Mutex *mx);
> typedef bool (*MutexLockFn)(Mutex *mx);
> typedef void (*MutexUnlockFn)(Mutex *mx);
> #else
> typedef Mutex *(*MutexNewFn)();
> typedef void (*MutexFreeFn)(Mutex *mx);
> typedef void (*MutexLockFn)(Mutex *mx);
> typedef void (*MutexUnlockFn)(Mutex *mx);
> #endif//DBUS_HAS_RECURSIVE_MUTEX
>
> ...
>
> #ifdef DBUS_HAS_THREADS_INIT_DEFAULT
> void DXXAPI _init_threading();
> #endif//DBUS_HAS_THREADS_INIT_DEFAULT
>
> The compiler flag is decided while compiling dbus-c++. Same defines are
> also in dispatcher.cpp. So if you compile dbus-c++ with
> DBUS_HAS_RECURSIVE_MUTEX activated and an user application with
> DBUS_HAS_RECURSIVE_MUTEX not activated you'll probably get a segfault
> or other strange behaviour.
>
> My proposal is the following:
>
> dispatcher.h:
> #ifdef DBUS_HAS_THREADS_INIT_DEFAULT
> void DXXAPI _init_threading();
> #endif//DBUS_HAS_THREADS_INIT_DEFAULT
>
> should be:
> void DXXAPI _init_threading();
>
>
> dispatcher.cpp:
> #ifdef DBUS_HAS_THREADS_INIT_DEFAULT
> void DBus::_init_threading()
> {
>        dbus_threads_init_default();
> }
> #endif//DBUS_HAS_THREADS_INIT_DEFAULT
>
> should be:
>
> void DBus::_init_threading()
> {
> #ifdef DBUS_HAS_THREADS_INIT_DEFAULT
>        dbus_threads_init_default();
> #else
>        cerr << "Thread support is not enabled! your D-Bus version is
>                 too old" << endl;
> #endif//DBUS_HAS_THREADS_INIT_DEFAULT
> }
>
> So client applications simply call _init_threading() in each case
> instead of using a compile time flag.
>
> TO remove the usage of DBUS_HAS_RECURSIVE_MUTEX I'm not really sure.
> But it's the same problem. Maybe it's possible to write some wrapper
> functions that always returns a boolean. So for the case
> of !DBUS_HAS_RECURSIVE_MUTEX it simply returns a "false" instead of a
> void to be be API compatible in both cases.
>
> What do you think? Should I provide a patch for that?
>
> regards
> Andreas
>

DBUS_HAS_RECURSIVE_MUTEX, DBUS_HAS_THREADS_INIT_DEFAULT and
DBUS_API_SUBJECT_TO_CHANGE date to the time before dbus 1.0 came to
be, we should drop this legacy hacks and only support the stable (>=
1.0) versions of libdbus as they're what people and distributions are
supposed to be using

regards,
Paolo

Re: [dbus-cplusplus-devel] Proposal: Give objects through dbus-c++

[P. D. <sh...@gm...>]

Hi,

On Sat, Aug 30, 2008 at 12:24 AM, Andreas Volz <li...@br...> wrote:
> Hello,
>
> while writing a DBUS interface for my application I found a way to give
> objects direct "through" DBUS. In reality the objects aren't give through
> DBUS. Only the copyable contents are given though DBUS.
>
> So how does it work?
>
> See the example communication framework here. It's only a prototype and
> still has some problems.
>
> http://tux-style.de/tmp/oicf-0.1.tar.gz
>
> Look at OICFControlListener.cpp: (below as reference. Use the source for more overview)
>
> class OICFControlListener :
>  public org::oicf::ControlListener,
>  public DBus::IntrospectableProxy,
>  public DBus::ObjectProxy
> {
> public:
>  OICFControlListener ( DBus::Connection& connection, const char* path, const char* name )
>  : DBus::ObjectProxy (connection, path, name) {}
>
>  virtual void onAxisListener (const KeyEvent &event) = 0;
>  virtual void onButtonListener (const KeyEvent &event) = 0;
>
> private:
>  void onAxisListener(const KeyEvent_Dbus_t &eventAxis)
>  {
>    KeyEvent event;
>    event << eventAxis;
>
>    onAxisListener (event);
>  }
>
>  void onButtonListener(const KeyEvent_Dbus_t &eventButton)
>  {
>    KeyEvent event;
>    event << eventButton;
>
>    onButtonListener (event);
>  }
>
> };
>
> As you see the private onAxisListener() from dbus-c++ is overwritten and creates
> the object KeyEvent, fills it with the '<<' operator and calls the new public
> callback function.
>
> Look into KeyEvent.h:

I've perused the archive but can't find this file

>
> typedef ::DBus::Struct <int32_t, int16_t, uint8_t, bool> KeyEvent_Dbus_t;
>
> class KeyEvent
> {
> public:
> ...
>
> public:
>  int32_t time;
>  int16_t value;
>  int8_t number;
>
> public:
>  void operator << (const KeyEvent_Dbus_t& event)
>  {
>    time = event._1;
>    value = event._2;
>    number = event._3;
>  }
> };
>

from what I've read you basically want to automate marshaling and
unmarshaling of DBus structured types, is that correct?
if this where to be done in the code generator, where would the field
names (in this case, "time", "value", "number") be stored? in the xml?

> This works as long as '<<' and '>>' operator is implemented correct in the class you like
> to give "through" dbus-c++. (See CoordWGS84.h) for another example.
>

this file can't be found either :-\

> For sure objects are not given through DBUS, but it looks and behaves for the user
> in that way.
>
> Look at the introspection XML:
>
> <?xml version="1.0" ?>
> <node name="/org/oicf/ControlListener">
>  <interface name="org.oicf.ControlListener">
>
>    <signal name="onAxisListener">
>      <arg type="(inyb)" name="eventAxis" direction="out"/>
>    </signal>
>
>    <signal name="onButtonListener">
>      <arg type="(inyb)" name="eventButton" direction="out"/>
>    </signal>
>
>  </interface>
>
> </node>
>
> You see that it has a struct that exactly fits the KeyEvent.h data.
>
> This works so far, but it's much way to write all that wrapper functions on my own. This
> is exact the work a code generator is done for. I would propose to change the XML format
> in that way:
>
> <?xml version="1.0" ?>
> <node name="/org/oicf/ControlListener">
>  <interface name="org.oicf.ControlListener">
>
>    <signal name="onAxisListener">
>      <arg type="(inyb)" name="eventAxis" direction="out" object="KeyEvent"/>
>    </signal>
>
>    <signal name="onButtonListener">
>      <arg type="(inyb)" name="eventButton" direction="out" object="KeyEvent"/>
>    </signal>
>
>  </interface>
>
> </node>
>
>
> So the code generator know that he should add some code to give "class KeyEvent" in a
> "KeyEvent.h" in dbus-c++ as shown above. The only thing that has to be hand written
> is the KeyEvent.h and the '<<' and '>>' operator.
>
> This proposal is backwards compatible as other DBUS implementations simply ignore the "object"
> tag and give access to the data with the normal DBUS mechanisms.
>

XML interfaces are supposed to be distributed to allow interoperation
with other applications and/or languages, since this addition would be
very specific to this particular implementation it could be
implemented using a dedicated annotation, other languages and bindings
(Glib and Qt come to mind) already do it, see

http://dbus.freedesktop.org/doc/dbus-specification.html

and look for "annotations"

> What do you think about this idea?
>

from what I understand you basically want to implement CORBA
ValueTypes in DBus :-)

> regards
> Andreas
>

regards,
Paolo

Re: [dbus-cplusplus-devel] [PATCH] Commented out unused variables.

[P. D. <sh...@gm...>]

On Sun, Aug 31, 2008 at 2:06 PM, Marko Anastasov
<mar...@gm...> wrote:
> Andreas Volz wrote:
>> Am Sun, 31 Aug 2008 13:17:40 +0200 schrieb Marko Anastasov:
>>
>>> Hi,
>>> Here's a trivial patch to prevent warnings when
>>> compiling client programs.
>>>
>>>      Marko
>>
>> Hello Marko,
>>
>> you should add a note with GIT repo this patch is for. We've currently
>> that official one on freedesktop.org and that on gitorious.org.
>
> It's for the one on freedesktop.org.
>
>     Marko
>
committed, thanks!

Re: [dbus-cplusplus-devel] [PATCH] Commented out unused variables.

[Marko A. <mar...@gm...>]

Andreas Volz wrote:
> Am Sun, 31 Aug 2008 13:17:40 +0200 schrieb Marko Anastasov:
> 
>> Hi,
>> Here's a trivial patch to prevent warnings when
>> compiling client programs.
>>
>>      Marko
> 
> Hello Marko,
> 
> you should add a note with GIT repo this patch is for. We've currently
> that official one on freedesktop.org and that on gitorious.org.

It's for the one on freedesktop.org.

     Marko

Re: [dbus-cplusplus-devel] [PATCH] Commented out unused variables.

[Andreas V. <li...@br...>]

Am Sun, 31 Aug 2008 13:17:40 +0200 schrieb Marko Anastasov:

> Hi,
> Here's a trivial patch to prevent warnings when
> compiling client programs.
> 
>      Marko

Hello Marko,

you should add a note with GIT repo this patch is for. We've currently
that official one on freedesktop.org and that on gitorious.org.

regards
Andreas

[dbus-cplusplus-devel] [PATCH] Commented out unused variables.

[Marko A. <mar...@gm...>]

Hi,
Here's a trivial patch to prevent warnings when
compiling client programs.

     Marko

[dbus-cplusplus-devel] glib example patch

[Andreas V. <li...@br...>]

Hello,

I'm not sure if my freedesktop GIT account does yet work. So I add a
patch to the new patch manager on sourceforge. The categories and so on
needs more work, but I think it would be useful to handle patches:

https://sourceforge.net/tracker/index.php?func=detail&aid=2083944&group_id=236997&atid=1101684

Or do you prefer another patch management?

regards
Andreas

[dbus-cplusplus-devel] #define problem in dispatcher.h/.cpp

[Andreas V. <li...@br...>]

Hello,

there's still a problem in dispatcher.h.

#ifndef DBUS_HAS_RECURSIVE_MUTEX
typedef Mutex *(*MutexNewFn)();
typedef bool (*MutexFreeFn)(Mutex *mx);
typedef bool (*MutexLockFn)(Mutex *mx);
typedef void (*MutexUnlockFn)(Mutex *mx);
#else
typedef Mutex *(*MutexNewFn)();
typedef void (*MutexFreeFn)(Mutex *mx);
typedef void (*MutexLockFn)(Mutex *mx);
typedef void (*MutexUnlockFn)(Mutex *mx);
#endif//DBUS_HAS_RECURSIVE_MUTEX

...

#ifdef DBUS_HAS_THREADS_INIT_DEFAULT
void DXXAPI _init_threading();
#endif//DBUS_HAS_THREADS_INIT_DEFAULT

The compiler flag is decided while compiling dbus-c++. Same defines are
also in dispatcher.cpp. So if you compile dbus-c++ with
DBUS_HAS_RECURSIVE_MUTEX activated and an user application with
DBUS_HAS_RECURSIVE_MUTEX not activated you'll probably get a segfault
or other strange behaviour.

My proposal is the following:

dispatcher.h:
#ifdef DBUS_HAS_THREADS_INIT_DEFAULT
void DXXAPI _init_threading();
#endif//DBUS_HAS_THREADS_INIT_DEFAULT

should be:
void DXXAPI _init_threading();


dispatcher.cpp:
#ifdef DBUS_HAS_THREADS_INIT_DEFAULT
void DBus::_init_threading()
{
	dbus_threads_init_default();
}
#endif//DBUS_HAS_THREADS_INIT_DEFAULT

should be:

void DBus::_init_threading()
{
#ifdef DBUS_HAS_THREADS_INIT_DEFAULT
	dbus_threads_init_default();
#else
	cerr << "Thread support is not enabled! your D-Bus version is
                 too old" << endl;
#endif//DBUS_HAS_THREADS_INIT_DEFAULT
}

So client applications simply call _init_threading() in each case
instead of using a compile time flag.

TO remove the usage of DBUS_HAS_RECURSIVE_MUTEX I'm not really sure.
But it's the same problem. Maybe it's possible to write some wrapper
functions that always returns a boolean. So for the case
of !DBUS_HAS_RECURSIVE_MUTEX it simply returns a "false" instead of a
void to be be API compatible in both cases.

What do you think? Should I provide a patch for that?

regards
Andreas

[dbus-cplusplus-devel] Proposal: Give objects through dbus-c++

[Andreas V. <li...@br...>]

Hello,

while writing a DBUS interface for my application I found a way to give
objects direct "through" DBUS. In reality the objects aren't give through
DBUS. Only the copyable contents are given though DBUS.

So how does it work?

See the example communication framework here. It's only a prototype and
still has some problems.

http://tux-style.de/tmp/oicf-0.1.tar.gz

Look at OICFControlListener.cpp: (below as reference. Use the source for more overview)

class OICFControlListener : 
  public org::oicf::ControlListener,
  public DBus::IntrospectableProxy,
  public DBus::ObjectProxy
{
public:
  OICFControlListener ( DBus::Connection& connection, const char* path, const char* name )
  : DBus::ObjectProxy (connection, path, name) {}
  
  virtual void onAxisListener (const KeyEvent &event) = 0;
  virtual void onButtonListener (const KeyEvent &event) = 0;
    
private:
  void onAxisListener(const KeyEvent_Dbus_t &eventAxis)
  {
    KeyEvent event;
    event << eventAxis;
    
    onAxisListener (event);
  }
    
  void onButtonListener(const KeyEvent_Dbus_t &eventButton)
  {
    KeyEvent event;
    event << eventButton;
    
    onButtonListener (event);
  }

};

As you see the private onAxisListener() from dbus-c++ is overwritten and creates 
the object KeyEvent, fills it with the '<<' operator and calls the new public
callback function.

Look into KeyEvent.h:

typedef ::DBus::Struct <int32_t, int16_t, uint8_t, bool> KeyEvent_Dbus_t;

class KeyEvent
{
public:
...
  
public:
  int32_t time;
  int16_t value;
  int8_t number;

public:
  void operator << (const KeyEvent_Dbus_t& event)
  {
    time = event._1;
    value = event._2;
    number = event._3;
  }
};

This works as long as '<<' and '>>' operator is implemented correct in the class you like
to give "through" dbus-c++. (See CoordWGS84.h) for another example.

For sure objects are not given through DBUS, but it looks and behaves for the user
in that way.

Look at the introspection XML:

<?xml version="1.0" ?>
<node name="/org/oicf/ControlListener">
  <interface name="org.oicf.ControlListener">

    <signal name="onAxisListener">
      <arg type="(inyb)" name="eventAxis" direction="out"/>
    </signal>

    <signal name="onButtonListener">
      <arg type="(inyb)" name="eventButton" direction="out"/>
    </signal>

  </interface>

</node>

You see that it has a struct that exactly fits the KeyEvent.h data.

This works so far, but it's much way to write all that wrapper functions on my own. This
is exact the work a code generator is done for. I would propose to change the XML format 
in that way:

<?xml version="1.0" ?>
<node name="/org/oicf/ControlListener">
  <interface name="org.oicf.ControlListener">

    <signal name="onAxisListener">
      <arg type="(inyb)" name="eventAxis" direction="out" object="KeyEvent"/>
    </signal>

    <signal name="onButtonListener">
      <arg type="(inyb)" name="eventButton" direction="out" object="KeyEvent"/>
    </signal>

  </interface>

</node>


So the code generator know that he should add some code to give "class KeyEvent" in a 
"KeyEvent.h" in dbus-c++ as shown above. The only thing that has to be hand written
is the KeyEvent.h and the '<<' and '>>' operator.

This proposal is backwards compatible as other DBUS implementations simply ignore the "object"
tag and give access to the data with the normal DBUS mechanisms.

What do you think about this idea?

regards
Andreas

Re: [dbus-cplusplus-devel] dbus-c++ doesn't work?

[Claudio C. <ck...@gm...>]

yes now it works!
thank you very much for your great job :D

regards,
Claudio Contino

On Mon, Aug 18, 2008 at 11:36 PM, P. Durante <sh...@gm...> wrote:

> On Mon, Aug 18, 2008 at 2:45 PM, Claudio Contino <ck...@gm...> wrote:
> > Hello,
> >
> > I'm a computer science student and I need an IPC API written in C++ for a
> > project I'm working at. I thought DBUS was the best choice, but I have
> some
> > problems with C++ bindings.
> > I have written this very very simple piece of code:
> >
> > #include <dbus-c++-1/dbus-c++/dbus.h>
> >
> > DBus::BusDispatcher dispatcher;
> >
> > int main()
> > {
> >     DBus::default_dispatcher = &dispatcher;
> >     DBus::Connection bus = DBus::Connection::SessionBus();
> >     return 0;
> > }
> >
> > but I get a segmentation fault on DBus::Connection::SessionBus();
> > this is the backtrace stack:
> >
> > #0 0xb7edbfb7    std::_List_node_base::hook()
> (/usr/lib/libstdc++.so.6:??)
> > #1 0xb7f9d340    DBus::Dispatcher::queue_connection()
> > (/usr/lib/libdbus-c++-1.so.0:??)
> > #2 0xb7f99089    DBus::Connection::setup()
> (/usr/lib/libdbus-c++-1.so.0:??)
> > #3 0xb7f9a943    DBus::Connection::Connection()
> > (/usr/lib/libdbus-c++-1.so.0:??)
> > #4 0xb7f9b1d7    DBus::Connection::SessionBus()
> > (/usr/lib/libdbus-c++-1.so.0:??)
> > #5 0x804b2fb    main()
> > (/home/claudio/Documents/progetti/codeblocks/dbus_prova/main.cpp:8)
> >
> > I'm using dbus-c++ compiled today from GIT and dbus daemon 1.2.3
> > should I move to another API or I am doing something incorrect?
> >
> > thanks,
> > Claudio Contino
> >
> > _______________________________________________
> > dbus mailing list
> > db...@li...
> > http://lists.freedesktop.org/mailman/listinfo/dbus
> >
> >
>
> the current version ought to work, my bad
>
> sorry,
> Paolo
>

Re: [dbus-cplusplus-devel] dbus-c++ doesn't work?

[Claudio C. <ck...@gm...>]

I joined the other mailing list (for new people: the discussion started here
http://lists.freedesktop.org/archives/dbus/2008-August/010287.html)

I tried to add the macros and to compile with -pthread as you suggest, but I
get the same result :( also tried to download dbus-cplusplus but it fail
while compiling the example echo-client:

echo_client_mt-echo-client.o: In function
`main':
echo-client.cpp:(.text+0xa3): undefined reference to
`pthread_create'
echo-client.cpp:(.text+0xc2): undefined reference to
`pthread_create'
echo-client.cpp:(.text+0xe1): undefined reference to
`pthread_create'
echo-client.cpp:(.text+0x128): undefined reference to
`pthread_join'
echo-client.cpp:(.text+0x13b): undefined reference to
`pthread_join'
echo-client.cpp:(.text+0x14e): undefined reference to
`pthread_join'
collect2: ld returned 1 exit status

I have installed libpthread of course! so I substitute echo-client.cpp (and
echo-server.cpp too) with a "do nothing" int main() {return 0;} and now I
can compile dbus-cplusplus successfully.
however I get again a segmentation fault running my simple example (compiled
both with and without -pthread option), can you reproduce this behavior too?

regards,
Claudio Contino

On Mon, Aug 18, 2008 at 10:16 PM, Andreas Volz <li...@br...> wrote:

> Am Mon, 18 Aug 2008 14:45:02 +0200 schrieb Claudio Contino:
>
> > Hello,
> >
> > I'm a computer science student and I need an IPC API written in C++
> > for a project I'm working at. I thought DBUS was the best choice, but
> > I have some problems with C++ bindings.
> > I have written this very very simple piece of code:
> >
> > #include <dbus-c++-1/dbus-c++/dbus.h>
> >
> > DBus::BusDispatcher dispatcher;
> >
> > int main()
> > {
> >     DBus::default_dispatcher = &dispatcher;
> >     DBus::Connection bus = DBus::Connection::SessionBus();
> >     return 0;
> > }
> >
> > but I get a segmentation fault on DBus::Connection::SessionBus();
> > this is the backtrace stack:
> >
> > #0 0xb7edbfb7    std::_List_node_base::hook()
> > (/usr/lib/libstdc++.so.6:??) #1 0xb7f9d340
> > DBus::Dispatcher::queue_connection() (/usr/lib/libdbus-c++-1.so.0:??)
> > #2 0xb7f99089    DBus::Connection::setup()
> > (/usr/lib/libdbus-c++-1.so.0:??) #3 0xb7f9a943
> > DBus::Connection::Connection() (/usr/lib/libdbus-c++-1.so.0:??)
> > #4 0xb7f9b1d7    DBus::Connection::SessionBus()
> > (/usr/lib/libdbus-c++-1.so.0:??)
> > #5 0x804b2fb    main()
> > (/home/claudio/Documents/progetti/codeblocks/dbus_prova/main.cpp:8)
> >
> > I'm using dbus-c++ compiled today from GIT and dbus daemon 1.2.3
> > should I move to another API or I am doing something incorrect?
>
> I've an ideas what the problem could be. Try to insert this at the
> start of your app:
>
> #define DBUS_HAS_THREADS_INIT_DEFAULT
> #define DBUS_HAS_RECURSIVE_MUTEX
> #define HAVE_PTHREAD 1
> #define HAVE_PTHREAD_H 1
>
> Then compile your demo application with -pthread option.
>
> Alternative try my the unofficial GIT repo here:
>
> http://gitorious.org/projects/dbus-cplusplus
>
> Would be interesting if you get the same crash. I assume it's a problem
> with pthread runtime dependency. If it works then I'll add some more
> words about that topic.
>
> BTW: You may discuss that topic on the list
> <dbu...@li...> if you like. Join
> here:
>
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
>
> regards
> Andreas
>
> -
> _______________________________________________
> dbus mailing list
> db...@li...
> http://lists.freedesktop.org/mailman/listinfo/dbus
>

Re: [dbus-cplusplus-devel] dbus-c++ project on sourceforge created

[P. D. <sh...@gm...>]

On Mon, Aug 18, 2008 at 10:25 PM, Andreas Volz <li...@br...> wrote:
> Am Sun, 17 Aug 2008 15:34:49 +0200 schrieb P. Durante:
>
>> On Sun, Aug 17, 2008 at 11:21 AM, Christopher Lang
>> <chr...@ac...> wrote:
>> >
>> > Paolo,
>> >
>> > a question on your code:
>> >
>> > what is that "private" stuff all about? For example in class
>> > "Connection" you are using this:
>> >
>> > class DXXAPI Connection
>> > ...
>> > 59      struct Private;
>> > 60
>> > 61      typedef std::list<Private*> PrivatePList;
>> > 62
>> > 63      Connection( Private* );
>> >
>> > Could you provide a little bit of rationale about this? It somehow
>> > confuses me. Is this simply a "private" dbus connection for example
>> > "app to app" connection? Or is this some (to me unknown) technique
>> > to produce c++ quasi private members in the "public" section?
>> >
>> > many thanks
>> >
>> > Chris
>> >
>> >
>>
>> it's not a private connection, it's the "private data" of that
>> particular class, objects and messages have private data too
>>
>> it's the typical pimpl pattern
>>
>> http://en.wikipedia.org/wiki/Pimpl
>>
>> and it serves two purposes:
>>
>> -copying semantics-
>> DBus::Connection objects (and any object implementing the same idiom)
>> can be copied and all copies will refer to the same, internal, libdbus
>> connection, reference counting is greatly simplified (look at the copy
>> constructor in connection.cpp)
>>
>> -isolation-
>> the public interface of the library (that is, the files under
>> include/) does not depend on libdbus, <dbus/dbus.h> is ONLY EVER
>> included from implementation files (under src/)
>
>
> Thanks for your explanations. I never used that design pattern. But it
> sounds interesting. I'll implement some samples the next days to get
> deeper into this design principle.
>
> As I understood it we could maybe solve that pthread runtime problem
> with the Pimpl design. In eventloop.h is this:
>
> class DXXAPI DefaultMutex
> {
> public:
>
>        DefaultMutex();
>
>        ~DefaultMutex();
>
>        void lock();
>
>        void unlock();
>
> private:
>
> #if defined HAVE_PTHREAD_H
>
>        pthread_mutex_t _mutex;
>
> #elif defined HAVE_WIN32
>
> //TODO: use a critical section
>
> #endif
> };
>
> This was the reason for the private config header. Because if you
> compile dbus-c++ with HAVE_PTHREAD_H and then the app without you'll
> get a silent crash. Wouldn't a Pimpl implementation help here to avoid
> the private config header?
>

yes but in this case it really isn't worth it, I used to want a native
windows but since pthreads already works on windows I just made it a
requirement on the last commit

of course this removes the shameful bug reported earlier today

> regards
> Andreas
>

regards

Re: [dbus-cplusplus-devel] dbus-c++ project on sourceforge created

[Andreas V. <li...@br...>]

Am Sun, 17 Aug 2008 15:34:49 +0200 schrieb P. Durante:

> On Sun, Aug 17, 2008 at 11:21 AM, Christopher Lang
> <chr...@ac...> wrote:
> >
> > Paolo,
> >
> > a question on your code:
> >
> > what is that "private" stuff all about? For example in class
> > "Connection" you are using this:
> >
> > class DXXAPI Connection
> > ...
> > 59      struct Private;
> > 60
> > 61      typedef std::list<Private*> PrivatePList;
> > 62
> > 63      Connection( Private* );
> >
> > Could you provide a little bit of rationale about this? It somehow
> > confuses me. Is this simply a "private" dbus connection for example
> > "app to app" connection? Or is this some (to me unknown) technique
> > to produce c++ quasi private members in the "public" section?
> >
> > many thanks
> >
> > Chris
> >
> >
> 
> it's not a private connection, it's the "private data" of that
> particular class, objects and messages have private data too
> 
> it's the typical pimpl pattern
> 
> http://en.wikipedia.org/wiki/Pimpl
> 
> and it serves two purposes:
> 
> -copying semantics-
> DBus::Connection objects (and any object implementing the same idiom)
> can be copied and all copies will refer to the same, internal, libdbus
> connection, reference counting is greatly simplified (look at the copy
> constructor in connection.cpp)
> 
> -isolation-
> the public interface of the library (that is, the files under
> include/) does not depend on libdbus, <dbus/dbus.h> is ONLY EVER
> included from implementation files (under src/)


Thanks for your explanations. I never used that design pattern. But it
sounds interesting. I'll implement some samples the next days to get
deeper into this design principle.

As I understood it we could maybe solve that pthread runtime problem
with the Pimpl design. In eventloop.h is this:

class DXXAPI DefaultMutex
{
public:

        DefaultMutex();

        ~DefaultMutex();

        void lock();

        void unlock();

private:

#if defined HAVE_PTHREAD_H

        pthread_mutex_t _mutex;

#elif defined HAVE_WIN32

//TODO: use a critical section

#endif
};

This was the reason for the private config header. Because if you
compile dbus-c++ with HAVE_PTHREAD_H and then the app without you'll
get a silent crash. Wouldn't a Pimpl implementation help here to avoid
the private config header?

regards
Andreas

Re: [dbus-cplusplus-devel] dbus-c++ project on sourceforge created

[Andreas V. <li...@br...>]

Am Mon, 18 Aug 2008 14:05:00 +0200 schrieb Christopher Lang:

> 
> Andreas,
> 
> > fundamental design changes. In my eyes it's sometimes better to do
> > and
> No, since Paolo privided some insight into the "private" pimpl
> technique, the design seems to be ok.
> 
> If I do changes, they will be small initially and maybe will only be 
> documentation or test routines (if even I find time to do
> anything...).
> 
> The reason I am asking for the "relevant "repository is quite simple:
> I want to make sure that changes get committed, or discussed &
> rejected; nothing  is more frustrating than sending diffs nobody
> cares about. :-)
> 
> Ok, so for the time being I will use the gitourious repo, I trust
> that sooner or later you will be able to make sure our stuff gets
> merged with the "official" repo. As you say: "has to arise in near
> future".

This is ok. I'll simply apply your changes after a short review. Simply
send patches to me. Alternative I could add you to the commiter list if
you only like to add smaller things. Send me your gitourous user name.
I'll later merge it back.

regards
Andreas