Forum: Ruby-Gnome 2 Any plans for Dbus?

Hello,

I was thinking of adding some Dbus[1] capability to an app, at this
moment only to connect to other applications, not to expose any
interface myself.

There are some bindings available for ruby[2], but they are old and
unmaintained and so have bitrotted so far they are unbuildable (and I
don't know how to fix it or even if it's easy/worth it).

It looks like GNOME (and KDE, and more) are pushing this technology a
lot now, so it looks like it's going to be very convenient to have it
for ruby-gnome applications. There are a lot of bindings for other
languages[3], including a Glib binding, which is what brings me here:
is this something that this project is thinking about including in the
future? (Or does anyone know of any other solution, for that matter).

1. http://www.freedesktop.org/wiki/Software/dbus
2. http://rubyforge.org/projects/dbus-ruby/
3. http://www.freedesktop.org/wiki/Software_2fDBusBindings

Thanks,

-- kristoffer

--
Kristoffer Lundén
✉ kristoffer.lunden@gmail.com
✉ kristoffer.lunden@gamemaker.nu
http://www.gamemaker.nu/
☎ 0704 48 98 77
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

On 1/25/07, Kristoffer Lundén <kristoffer.lunden@gmail.com> wrote:

> I was thinking of adding some Dbus[1] capability to an app, at this
> moment only to connect to other applications, not to expose any
> interface myself.
>
> There are some bindings available for ruby[2], but they are old and
> unmaintained and so have bitrotted so far they are unbuildable (and I
> don't know how to fix it or even if it's easy/worth it).

I think the best place to add these bindings would be to the DBus
distribution, as they really belong together with the other bindings
(such as the GLib and Python bindings), not with the ruby-gnome2
bindings.

  nikolai

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

On 1/25/07, Nikolai Weibull <now@bitwi.se> wrote:
> I think the best place to add these bindings would be to the DBus
> distribution, as they really belong together with the other bindings
> (such as the GLib and Python bindings), not with the ruby-gnome2
> bindings.

http://www.freedesktop.org/wiki/Software_2fDBusBindings

However, I realize now that you might need the GLib mainloop for D-Bus
(which apparently is the proper spelling), so perhaps you'll depend on
glib2 anyway and ruby-gnome2 is the right forum after all.

I'll shut up now.

  nikolai

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

On 1/25/07, Nikolai Weibull <now@bitwi.se> wrote:
> glib2 anyway and ruby-gnome2 is the right forum after all.
>

To be honest, I don't know myself. :) I do agree that ruby needs it's
own separate bindings, but the reason for asking here was that I saw
those GLib bindings and thought they might fit in with this project.
Whether I could use either should need one or the other is sadly above
my head... :)

Thanks for the answer!

-- Kristoffer


--
Kristoffer Lundén
✉ kristoffer.lunden@gmail.com
✉ kristoffer.lunden@gamemaker.nu
http://www.gamemaker.nu/
☎ 0704 48 98 77
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

On Thu, Jan 25, 2007 at 01:57:38PM +0100, Nikolai Weibull wrote:
> >
> > I think the best place to add these bindings would be to the DBus
> > distribution, as they really belong together with the other bindings
> > (such as the GLib and Python bindings), not with the ruby-gnome2
> > bindings.
> 
> http://www.freedesktop.org/wiki/Software_2fDBusBindings
> 
> However, I realize now that you might need the GLib mainloop for D-Bus
> (which apparently is the proper spelling), so perhaps you'll depend on
> glib2 anyway and ruby-gnome2 is the right forum after all.

You don't need the GLib mainloop (well not strictly) for D-Bus. Although 
it's
always nice to integrate with the GLib mainloop if you've got one 
anyway.

I've thought about starting with D-Bus bindings from time to time, but i 
just
don't have the time for it.

Anyway if your going to start with the bindings, do consider doing it 
entirely
in Ruby instead of on top of libdbus. From discussion i've had with the 
guy
implementing the new C# bindings, this might make various aspect 
actually
easier. See [0] for the full protocol specification.

  Sjoerd
0: http://dbus.freedesktop.org/doc/dbus-specification.html
--
All life evolves by the differential survival of replicating entities.
    -- Dawkins

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

On 1/25/07, Sjoerd Simons <sjoerd@spring.luon.net> wrote:
> I've thought about starting with D-Bus bindings from time to time, but i just
> don't have the time for it.
>
> Anyway if your going to start with the bindings, do consider doing it entirely
> in Ruby instead of on top of libdbus. From discussion i've had with the guy
> implementing the new C# bindings, this might make various aspect actually
> easier. See [0] for the full protocol specification.

This is probably a good idea to get a more rubyish interface from the
start as well, instead of wrapping c interfaces, then wrapping those
and then maintain both.  :)

However, before someone starts this, there might be a problem - I
looked at the spec and then I tried to connect to the socket on my
machine just to see if I could get a response, but I couldn't get a
connection at all. Reason for this is that D-BUS can, and on my
machine (Ubuntu) does, use something called an abstract unix socket,
which seems to be some kind of virtual socket... it has a path (in
/tmp in this case) but isn't in the filesystem, and so the Socket
library could not find it... maybe I'm doing something wrong, but I
couldn't find anything about connecting to these things in Ruby.

Just a heads up.

-- Kristoffer


--
Kristoffer Lundén
✉ kristoffer.lunden@gmail.com
✉ kristoffer.lunden@gamemaker.nu
http://www.gamemaker.nu/
☎ 0704 48 98 77
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

On Thu, Jan 25, 2007 at 04:40:14PM +0100, Kristoffer Lundén wrote:
> 
> However, before someone starts this, there might be a problem - I
> looked at the spec and then I tried to connect to the socket on my
> machine just to see if I could get a response, but I couldn't get a
> connection at all. Reason for this is that D-BUS can, and on my
> machine (Ubuntu) does, use something called an abstract unix socket,
> which seems to be some kind of virtual socket... it has a path (in
> /tmp in this case) but isn't in the filesystem, and so the Socket
> library could not find it... maybe I'm doing something wrong, but I
> couldn't find anything about connecting to these things in Ruby.

You connect to an abstract socket by specifying the first byte of the 
path as
'\0', unfortunately the ruby socket layer doesn't allow you to do this.. 
It
gives you:
  ArgumentError: string contains null byte

Seems to be quite trivial to patch though. Although you really want ruby
upstream to support it and i have no idea how hard that is (Not too 
difficult
hopefully)

  Sjoerd
--
No amount of careful planning will ever replace dumb luck.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

On 1/25/07, Sjoerd Simons <sjoerd@spring.luon.net> wrote:
> You connect to an abstract socket by specifying the first byte of the path as
> '\0', unfortunately the ruby socket layer doesn't allow you to do this.. It
> gives you:
>   ArgumentError: string contains null byte
>
> Seems to be quite trivial to patch though. Although you really want ruby
> upstream to support it and i have no idea how hard that is (Not too difficult
> hopefully)
>

Looks straightforward enough:
http://www.ruby-lang.org/en/community/ruby-core/#patching-ruby

Didn't find any bug about this in the bug tracker.

-- Kristoffer


--
Kristoffer Lundén
✉ kristoffer.lunden@gmail.com
✉ kristoffer.lunden@gamemaker.nu
http://www.gamemaker.nu/
☎ 0704 48 98 77
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

I found myself in the very same situation, so I started a new project at
Rubyforge, and have uploaded initial code for a ruby only implementation
of the dbus protocol.

Right now, it's quite unusable, though you can connect to the system bus
(no session bus, you know, that abstract socket thing), and may send
simple messages and receive the reply. Right now, there's no implicit
glib main loop integration, but I think it can still work with glib or
gtk applications. So give it a try, and if you can provide some help, it
will be really welcome
Kristoffer Lundén wrote:
> Hello,
> 
> I was thinking of adding some Dbus[1] capability to an app, at this
> moment only to connect to other applications, not to expose any
> interface myself.
> 
> There are some bindings available for ruby[2], but they are old and
> unmaintained and so have bitrotted so far they are unbuildable (and I
> don't know how to fix it or even if it's easy/worth it).
> 
> It looks like GNOME (and KDE, and more) are pushing this technology a
> lot now, so it looks like it's going to be very convenient to have it
> for ruby-gnome applications. There are a lot of bindings for other
> languages[3], including a Glib binding, which is what brings me here:
> is this something that this project is thinking about including in the
> future? (Or does anyone know of any other solution, for that matter).
> 
> 1. http://www.freedesktop.org/wiki/Software/dbus
> 2. http://rubyforge.org/projects/dbus-ruby/
> 3. http://www.freedesktop.org/wiki/Software_2fDBusBindings
> 
> Thanks,
> 
> -- kristoffer
> 
> --
> Kristoffer Lundén
> ✉ kristoffer.lunden@gmail.com
> ✉ kristoffer.lunden@gamemaker.nu
> http://www.gamemaker.nu/
> ☎ 0704 48 98 77
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share 
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Well there I get for forgetting to tell the world. ;-)

Anyhow, I also went ahead and created a library, though I haven't
started a Rubyforge project for it yet. And I know of at least one
more project like this, but that one had very different goals it
seemed.

It's actually starting to be usable, I am currently sitting here and
controlling Rhythmbox with it. It supports session and system (and any
random) bus, as I found out that abstract sockets are possible using
connect(). It supports authentications and messages, replies, async
replies and so on. In fact, for the client parts, almost all of the
foundation is there.

I have my own main loop instead, as I have as one goal that there
should be zero needed dependencies outside Ruby + Stdlib. Dunno how
that works with Glib, but there should be no problem adding an
optional extra. The API feels pretty rubyish too. ;-)

There's still some work to do before it's ready for initial release
IMO, but not too much: Stabilizing the marshaling, using introspection
automatically, adding signals, completing the test suite, licensing it
properly. Maybe exporting objects though that can wait a little. Apart
from getting the marshaling exactly right, which may or may not be
hard, none of this should be too big a task, so I expect to be ready
pretty soon, barring any surprises.

Not keeping it away from the masses any more that I have to, promise.
;-) Just trying to make sure it's usable *and* hackable when the first
version hits the internet, so I've both built a structure and a pretty
comprehensive test suite (RSpec).


-- Kristoffer


On 3/16/07, jals <ruby-forum-incoming@andreas-s.net> wrote:
> Kristoffer Lundén wrote:
> > It looks like GNOME (and KDE, and more) are pushing this technology a
> > Thanks,
> > Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> ruby-gnome2-devel-en mailing list
> ruby-gnome2-devel-en@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-en
>


--
Kristoffer Lundén
✉ kristoffer.lunden@gmail.com
✉ kristoffer.lunden@gamemaker.nu
http://www.gamemaker.nu/
☎ 0704 48 98 77
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

On Fri, Mar 16, 2007 at 06:16:14AM +0100, Kristoffer Lundén wrote:
> Well there I get for forgetting to tell the world. ;-)
> 
> Anyhow, I also went ahead and created a library, though I haven't
> started a Rubyforge project for it yet. And I know of at least one
> more project like this, but that one had very different goals it
> seemed.

It would be good if you guys talked together.. It won't be very nice to 
end up
with three slightly different implementations of the same thing :)

> It's actually starting to be usable, I am currently sitting here and
> controlling Rhythmbox with it. It supports session and system (and any
> random) bus, as I found out that abstract sockets are possible using
> connect(). It supports authentications and messages, replies, async
> replies and so on. In fact, for the client parts, almost all of the
> foundation is there.

  Nice work \o/

> I have my own main loop instead, as I have as one goal that there
> should be zero needed dependencies outside Ruby + Stdlib. Dunno how
> that works with Glib, but there should be no problem adding an
> optional extra. The API feels pretty rubyish too. ;-)

Your own mainloop is great ofcourse.. But it would really rock if it 
would have
some optional integration with the GLib mainloop was possible.. I really 
don't
want to run a mainloop for dbus, one for GLib, one for whatever 
framerwork in
my applications :)

Adding Glib mainloop support is probably nothing more then using a
GLib::IOChannel to watch your dbus connection and use that to trigger
the demarshalling.. Should be mostly trivial :)

  Sjoerd
--
Nothing is but what is not.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

>> And I know of at least one
>> more project like this, but that one had very different goals it
>> seemed.

That's probably paul and I. :)

> It would be good if you guys talked together.. It won't be very nice to 
> end up
> with three slightly different implementations of the same thing :)

Obviously yes.

>> It's actually starting to be usable, I am currently sitting here and
>> controlling Rhythmbox with it. It supports session and system (and any
>> random) bus, as I found out that abstract sockets are possible using
>> connect(). It supports authentications and messages, replies, async
>> replies and so on. In fact, for the client parts, almost all of the
>> foundation is there.

I also have a working implementation. I have a working dbus messages 
marshaller/unmarshaller, signature parser. I also have a 
ProxyObjectFactory object that generates proxy objects from XML 
definition, allowing runtime object class definition using D-Bus 
introspection mecanism.

All this works, now what's left to do:
- Auth. Right now it's stupid and hardcoded. Works for my tests. That's 
all.
More interesting stuff:
- Implement a way to provide methods rather than simply be able to call 
them.
- Implement proper GLib integration.

I have no idea on how to do that properly. Given a unix socket I can 
poll for message, detect their completeness, and process them. I think 
this will be enough to implement glib main loop integration. The api is 
definitely not set in stone anyway.

> Your own mainloop is great ofcourse.. But it would really rock if it 
> would have
> some optional integration with the GLib mainloop was possible.. I really 
> don't
> want to run a mainloop for dbus, one for GLib, one for whatever 
> framerwork in
> my applications :)

It's actually not possible to have multibple mainloops w/o threading. So 
yeah ! GLib main loop is the de facto standard for main loops. I would 
like a DBus lib to provide low level stuff to marshall/unmarshall 
messages, but also a very high level api that gives GObjects to connect 
signals to.

> Adding Glib mainloop support is probably nothing more then using a
> GLib::IOChannel to watch your dbus connection and use that to trigger
> the demarshalling.. Should be mostly trivial :)

Well, you certainly can help me on that. I have a ruby UNIXSocket, and I 
don't really know how to map it to a GIOChannel.

My source is available there: https://trac.luon.net/ruby-dbus/browser/
It's NOT in releasable shape. It needs a patch to the ruby interpeter to 
work (with linux, for the abstract socket stuff, see the contrib 
subdir).

Feel free to ask me whatever comes to your mind.
--
Arnaud Cornet

Somewhat bizarre to keep this on the Ruby-GNOME list perhaps, but ah
well. ;-) I would like input on what GLib stuff would help Gtk+/GNOME
applications, so as long as noone minds too much... :)

On 3/16/07, Arnaud Cornet <ruby-forum-incoming@andreas-s.net> wrote:
> >> And I know of at least one
> >> more project like this, but that one had very different goals it
> >> seemed.
>
> That's probably paul and I. :)
>

That's you, yes. :) I haven't forgotten about you guys, but I really
felt I had to make the big clean-up before there was any idea to put
it all up there. It's rare that releasing a mess will result in better
code, usually it will just get messier, or not used at all. :) That
said, the architecture is starting to look both logical and usable,
and as soon as it's glued together properly for the first time, it'll
be release early and often.

I'm also working to have a good test suite from the start, so it'll be
easy to keep working and stable. RSpec is fantastic if you haven't
checked it out.

> > It would be good if you guys talked together.. It won't be very nice to
> > end up
> > with three slightly different implementations of the same thing :)
>
> Obviously yes.
>

Agree, like I've said before. However, Arnaud and I have talked and I
think we have very different approaches and also differing goals, so I
think there is some things to be won by letting the different paths go
their merry way for a little while and maybe see what works, who is
"right" if you wish. ;-) I don't mind being wrong... it's also quite
possible that we can meet all our goals together later, but now it
didn't seem to be a good time to me. Sorry.

> I also have a working implementation. I have a working dbus messages
> marshaller/unmarshaller, signature parser. I also have a
> ProxyObjectFactory object that generates proxy objects from XML
> definition, allowing runtime object class definition using D-Bus
> introspection mecanism.

I have a somewhat similar, approach, but I don't rely on XML to always
be available, as it isn't. In many cases it's quite possible to do the
right thing anyway, and when all else fails you should be able to tell
the library what to do. Creating a Proxy object does involve asking
for an Introspect first though...

> All this works, now what's left to do:
> - Auth. Right now it's stupid and hardcoded. Works for my tests. That's
> all.

Got the state machine and mechanisms from the specs and it's easy to
plug new ones.

> More interesting stuff:
> - Implement a way to provide methods rather than simply be able to call
> them.

Are you talking about exporting objects or something else? Exporting
objects is an important goal IMO, and even more so to do it in a way
that feel natural to Ruby. :)

> - Implement proper GLib integration.

Not at all interested in this, unless there is a compelling reason .-
see below. :)

> like a DBus lib to provide low level stuff to marshall/unmarshall
> messages, but also a very high level api that gives GObjects to connect
> signals to.
>

I was a bit unclear. Actually I don't have a mainloop in that sense,
but all messages are sent and received in their own lightweight
thread, which handles sync and async messages and signals etc
seamlessly. The end user never sees anythig about this, but only makes
the requests. From what I can tell, if you start a Glib or any other
mainloop, things will just keep on working as they should.

I assume there's extra benefits if you have a GLib mainloop anyways to
be able to use those signals natively and stuff, but I think that
could easily be solved by importing an extra lib when it's available I
think. I'm not actually sure what people want here, but I am
interested to know. :)

And personally I think that GLib can be all the de facto standard it
wants, but it would be horrible to have that as anything but an
optional dependency. :)

> It needs a patch to the ruby interpeter to
> work (with linux, for the abstract socket stuff, see the contrib
> subdir).

@connection_info is a hash made from the server address parts, should
be pretty obvious from there:

    class UNIXTransport < AbstractTransport
      def create_socket
        if @connection_info.has_key?('abstract')
          @socket = Socket.new(Socket::AF_UNIX, Socket::SOCK_STREAM, 0)
          @socket.connect("\1\0\0#{@connection_info['abstract']}")
        elsif @connection_info.has_key?('path')
          @socket = UNIXSocket.open(@connection_info['path'])
        end
      end
    end

Ugly, isn't it? :) But no need for patches... I got the base for this
from the bug report I filed. From what I understood, I think at least
some devs thought this should not be patched in main, ever.


-- Kristoffer


Kristoffer Lundén
✉ kristoffer.lunden@gmail.com
✉ kristoffer.lunden@gamemaker.nu
http://www.gamemaker.nu/
☎ 0704 48 98 77
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

On Fri, Mar 16, 2007 at 08:22:38PM +0100, Kristoffer Lundén wrote:
> I was a bit unclear. Actually I don't have a mainloop in that sense,
> but all messages are sent and received in their own lightweight
> thread, which handles sync and async messages and signals etc
> seamlessly. The end user never sees anythig about this, but only makes
> the requests. From what I can tell, if you start a Glib or any other
> mainloop, things will just keep on working as they should.

Could you be a little more specific about this ? Maybe some 
(pseudo)-code
examples ? The approach sounds a little bit problamatic to me. But then 
again
I really dislike threads being spawned behind the users back, but maybe 
you
can prove me wrong here :)

> I assume there's extra benefits if you have a GLib mainloop anyways to
> be able to use those signals natively and stuff, but I think that
> could easily be solved by importing an extra lib when it's available I
> think. I'm not actually sure what people want here, but I am
> interested to know. :)


> And personally I think that GLib can be all the de facto standard it
> wants, but it would be horrible to have that as anything but an
> optional dependency. :)

I'd never ask to make it a mandatory dependency, that would be really 
bad.

  Sjoerd
--
The following statement is not true.  The previous statement is true.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Kristoffer Lundén wrote:
> Somewhat bizarre to keep this on the Ruby-GNOME list perhaps, but ah
> well. ;-) I would like input on what GLib stuff would help Gtk+/GNOME
> applications, so as long as noone minds too much... :)

I think you are right. I propose that we all start using a mailing list 
in one of our created projects. Of course I offer mine ;) (pr-dbus) for 
which I have already requested a mailing list. We can always use ruby 
forge's forums.

The truth is this thread prompted me to start writing something, and I 
think we now need a proper place for discussion. So, please hangout at 
http://rubyforge.org/projects/pr-dbus/

Or if you have another idea, please tell.

> 
> On 3/16/07, Arnaud Cornet <ruby-forum-incoming@andreas-s.net> wrote:
>> >> And I know of at least one
>> >> more project like this, but that one had very different goals it
>> >> seemed.
>>
>> That's probably paul and I. :)
>>
> 
> That's you, yes. :) I haven't forgotten about you guys, but I really
> felt I had to make the big clean-up before there was any idea to put
> it all up there. It's rare that releasing a mess will result in better
> code, usually it will just get messier, or not used at all. :) That
> said, the architecture is starting to look both logical and usable,
> and as soon as it's glued together properly for the first time, it'll
> be release early and often.
> 

I have had the very same feelings, but I decided I should start 
releasing now. In fact you can download from the subversion repository 
what I have right now, which seems to be a bit less than what you have. 
On the licensing side, I am using the LGPL right now.



> I'm also working to have a good test suite from the start, so it'll be
> easy to keep working and stable. RSpec is fantastic if you haven't
> checked it out.
> 
>> > It would be good if you guys talked together.. It won't be very nice to
>> > end up
>> > with three slightly different implementations of the same thing :)
>>
>> Obviously yes.
>>
> 
> Agree, like I've said before. However, Arnaud and I have talked and I
> think we have very different approaches and also differing goals, so I
> think there is some things to be won by letting the different paths go
> their merry way for a little while and maybe see what works, who is
> "right" if you wish. ;-) I don't mind being wrong... it's also quite
> possible that we can meet all our goals together later, but now it
> didn't seem to be a good time to me. Sorry.
> 
>> I also have a working implementation. I have a working dbus messages
>> marshaller/unmarshaller, signature parser. I also have a
>> ProxyObjectFactory object that generates proxy objects from XML
>> definition, allowing runtime object class definition using D-Bus
>> introspection mecanism.
> 
> I have a somewhat similar, approach, but I don't rely on XML to always
> be available, as it isn't. In many cases it's quite possible to do the
> right thing anyway, and when all else fails you should be able to tell
> the library what to do. Creating a Proxy object does involve asking
> for an Introspect first though...
> 
>> All this works, now what's left to do:
>> - Auth. Right now it's stupid and hardcoded. Works for my tests. That's
>> all.
> 
> Got the state machine and mechanisms from the specs and it's easy to
> plug new ones.
> 
>> More interesting stuff:
>> - Implement a way to provide methods rather than simply be able to call
>> them.
> 
> Are you talking about exporting objects or something else? Exporting
> objects is an important goal IMO, and even more so to do it in a way
> that feel natural to Ruby. :)
> 
>> - Implement proper GLib integration.
> 
> Not at all interested in this, unless there is a compelling reason .-
> see below. :)
> 
>> like a DBus lib to provide low level stuff to marshall/unmarshall
>> messages, but also a very high level api that gives GObjects to connect
>> signals to.
>>
> 
> I was a bit unclear. Actually I don't have a mainloop in that sense,
> but all messages are sent and received in their own lightweight
> thread, which handles sync and async messages and signals etc
> seamlessly. The end user never sees anythig about this, but only makes
> the requests. From what I can tell, if you start a Glib or any other
> mainloop, things will just keep on working as they should.
> 
> I assume there's extra benefits if you have a GLib mainloop anyways to
> be able to use those signals natively and stuff, but I think that
> could easily be solved by importing an extra lib when it's available I
> think. I'm not actually sure what people want here, but I am
> interested to know. :)
> 
> And personally I think that GLib can be all the de facto standard it
> wants, but it would be horrible to have that as anything but an
> optional dependency. :)
> 
>> It needs a patch to the ruby interpeter to
>> work (with linux, for the abstract socket stuff, see the contrib
>> subdir).
> 
> @connection_info is a hash made from the server address parts, should
> be pretty obvious from there:
> 
>     class UNIXTransport < AbstractTransport
>       def create_socket
>         if @connection_info.has_key?('abstract')
>           @socket = Socket.new(Socket::AF_UNIX, Socket::SOCK_STREAM, 0)
>           @socket.connect("\1\0\0#{@connection_info['abstract']}")
>         elsif @connection_info.has_key?('path')
>           @socket = UNIXSocket.open(@connection_info['path'])
>         end
>       end
>     end
> 
> Ugly, isn't it? :) But no need for patches... I got the base for this
> from the bug report I filed. From what I understood, I think at least
> some devs thought this should not be patched in main, ever.

So, to wrap it all... We all seem to have similar goals, so lets start 
working in the same direction.

On 3/18/07, Sjoerd Simons <sjoerd@spring.luon.net> wrote:
>
> Could you be a little more specific about this ? Maybe some (pseudo)-code
> examples ? The approach sounds a little bit problamatic to me. But then again
> I really dislike threads being spawned behind the users back, but maybe you
> can prove me wrong here :)
>

I can try. :) In general, I agree with you. Threads spawned behind the
back can be really bad, and I'm not saying that this will not change,
at least for the default. The main reasons for doing it this way is
that

a) it provides *all* the message types and transports ever needed for
a client with very few lines of code, making it easy to maintain, and

b) ease-of-use for the end user - *assuming* that the library is
bug-free, the user does not have to care about any loops or anything
unless he absolutely wants to.


I don't know about pseudo-code, but in general, you can do things like
this (works today):

  # Plain no frills sync call
  puts object.GetSomeData

  # Async call
  object.DoSomeTakeALongTimeOperation { |result|
    puts results
  }

  puts "Meanwhile..."

Which would print the SomeData, "Meanwhile..." and lastly results.
It's all taken care of, just give the method a block and move on. This
also means you can make a lot of calls in parallell.

The thread goes away when the bus goes away, and I think I'll add
blocks to the bus connections, like many other Ruby libs, that will
scope the loop and the object to that:


  RBus.session_bus do |bus|
    bus.get_object...
    ...
  end
  # Here the thread is gone and the connection closed etc.

Threads can be scary though, but if you keep it easy enough, it should
be safe, and Ruby has very good threads that are easy to manage.

The actual implementation is a very simple loop that fetches new
messages and the uses the Observer pattern to notify any waiting calls
of a reply. When a call is made, or a signal registered, or a method
exported, the library just attaches an appropriate Observer that knows
what to listen for, which then does the right thing. For the simplest
case, this is waiting for a reply, for more async calls etc. it means
registering a callback.

The whole thing is built on a chain of objects doing their thing
though, so I think it would be very easy to provide multiple
implementations and let the end user choose what kind of functionality
is appropriate, by requiring different base libs perhaps? Say
'rbus/easy' for the auto-threads, 'rbus' for no frills, sync only,
'rbus/glib' for using GLib IO channels and so on. That would probably
satisfy everyone and if that's easy, it'll be easy to add more
implementations as needed.



--
Kristoffer Lundén
✉ kristoffer.lunden@gmail.com
✉ kristoffer.lunden@gamemaker.nu
http://www.gamemaker.nu/
☎ 0704 48 98 77
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Whoops stupid fingers just sent a mail that wasn't finished. But ah 
well.

I was just going to ask about the GLib IO channels, haven't looked
them up, but am I correct in assuming that for this it's basically
selects on a socket, with a callback? That'd be really easy to add.

And also, please feel free to ask more questions, or ask me to leave,
it's a bit OT unless it's of interest to this list. ;-)

-- Kristoffer


On 3/19/07, Kristoffer Lundén <kristoffer.lunden@gmail.com> wrote:
> at least for the default. The main reasons for doing it this way is
> I don't know about pseudo-code, but in general, you can do things like
>   puts "Meanwhile..."
>   RBus.session_bus do |bus|
> of a reply. When a call is made, or a signal registered, or a method
> 'rbus/glib' for using GLib IO channels and so on. That would probably
> ☎ 0704 48 98 77
>


--
Kristoffer Lundén
✉ kristoffer.lunden@gmail.com
✉ kristoffer.lunden@gamemaker.nu
http://www.gamemaker.nu/
☎ 0704 48 98 77
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

On Mon, Mar 19, 2007 at 12:28:26AM +0100, Jaime Atahualpa Lopez Sollano 
wrote:
> The truth is this thread prompted me to start writing something, and I 
> think we now need a proper place for discussion. So, please hangout at 
> http://rubyforge.org/projects/pr-dbus/

I'd say:
  https://lists.luon.net/listinfo/ruby-dbus-devel :)

Which is closely related to https://trac.luon.net/ruby-dbus. I think 
they
deserve some credit for being the first to actually have some working 
code
online..

  Sjoerd
--
Life may have no meaning, or, even worse, it may have a meaning of which
you disapprove.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Taking this of the ruby-gnome-2 list and moving to
ruby-dbus-devel@lists.luon.net

On Mon, Mar 19, 2007 at 12:48:09AM +0100, Kristoffer Lundén wrote:
> Whoops stupid fingers just sent a mail that wasn't finished. But ah well.
> 
> I was just going to ask about the GLib IO channels, haven't looked
> them up, but am I correct in assuming that for this it's basically
> selects on a socket, with a callback? That'd be really easy to add.

Yeah.. If your bindings have some function which indicates that there is 
some
data available, it's trivial..

> > > examples ? The approach sounds a little bit problamatic to me. But then again
> > a client with very few lines of code, making it easy to maintain, and
> >   puts object.GetSomeData
> > also means you can make a lot of calls in parallell.
> >
> > The thread goes away when the bus goes away, and I think I'll add
> > blocks to the bus connections, like many other Ruby libs, that will
> > scope the loop and the object to that:

So sync return in the thread you start them in, but async run them in 
the dbus
thread or does it spawn another one ?

  Sjoerd

On 3/19/07, Sjoerd Simons <sjoerd@spring.luon.net> wrote:
> Yeah.. If your bindings have some function which indicates that there is some
> data available, it's trivial..
>

Well the socket knows when there's read data available, just as with
selects. Looks like it could listen to that, meaning no problem at
all.

> So sync return in the thread you start them in, but async run them in the dbus
> thread or does it spawn another one ?
>

Every async call must by definition run in it's own thread, otherwise
it's not very async :). The actual message passing is in one single
thread so there's no race conditions though.

-- Kristoffer

On mar, mar 20, 2007 at 12:08:26 +0100, Kristoffer Lundén wrote:
> Every async call must by definition run in it's own thread, otherwise
> it's not very async :). The actual message passing is in one single
> thread so there's no race conditions though.

This is wrong, asynchronous call basically means that the caller does
not have to wait for the reply. By extension, it means that you can
fireup multiple calls to different methods at once, and recieve later a
batch of replies. A synchronous call would make you have to wait for a
reply before you can do the next call.

In a non-threaded world, that means that when you do the actuall call,
you have to setup a callback that will be triggered later, when the
reply is recieved. You can compute other stuff after sending the
call and recieving the reply.

Cheers,

Kristoffer Lundén wrote:
> On 3/19/07, Sjoerd Simons <sjoerd@spring.luon.net> wrote:
>> Yeah.. If your bindings have some function which indicates that there is some
>> data available, it's trivial..
>>
> 
> Well the socket knows when there's read data available, just as with
> selects. Looks like it could listen to that, meaning no problem at
> all.
> 
>> So sync return in the thread you start them in, but async run them in the dbus
>> thread or does it spawn another one ?
>>
> 
> Every async call must by definition run in it's own thread, otherwise
> it's not very async :). The actual message passing is in one single
> thread so there's no race conditions though.
> 
> -- Kristoffer

Hi there.

Any news?

On 4/7/07, Jaime A Lopez <ruby-forum-incoming@andreas-s.net> wrote:
>
> Hi there.
>
> Any news?
>

Hello,

nothing new in the last week or so, since I've been busy with other
things, but there is a release up on Rubyforge with everything
client-side except exporting objects, which is the next thing. Also
there's a bunch of examples, including an implementation of dbus-send
(rbus-send) and a tutorial and API docs. Still not 100% sure on the
API, input is welcome.

You can also get it with "gem install rbus".

Feel free to give it a spin and let me know what you think, any
input/contributions are welcome. There's bug trackers, forums, lists
and stuff like that on the project page, or you can just email me.

Homepage: http://rbus.rubyforge.org/
Project page: http://rubyforge.org/projects/rbus/
Docs, tutorial, HACKING etc: http://rbus.rubyforge.org/doc/

Thanks for the interest,

-- Kristoffer

> ruby-gnome2-devel-en@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-en
>


--
Kristoffer Lundén
✉ kristoffer.lunden@gmail.com
✉ kristoffer.lunden@gamemaker.nu
http://www.gamemaker.nu/
☎ 0704 48 98 77
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share 
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV