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 C. [email protected] 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
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