Re: [Haskell-cafe] ANNOUNCE: dbus-core 0.6 and dbus-client 0.2
Hi John,
Very nice work! As it happens, Dafydd Harries and I wrote another native
implementation of the D-Bus protocol, but yours is much more complete,
and the documentation/commentary is ace. A refreshing change from the
daily pain of libdbus and dbus-glib... :-)
I'm looking at modifying Bustle (which draws sequence diagrams of D-Bus
traffic; http://www.willthompson.co.uk/bustle/) to log raw D-Bus
messages to a pcap file, rather than the current custom text format that
includes just the information from the message the UI needs alongside a
timestamp. Then the UI would read the pcap file, and feed the data
through a D-Bus parser before processing it further. Now that there's a
decent D-Bus implementation available, it seems like a good time to have
a crack at this.
However, I can't find a way to feed a bytestring to dbus-core and get
back a ReceivedMessage. Is this deliberately not exposed? While it's
obviously not useful in general, it would be very useful for Bustle.
(The alternative is to construct a fake connection to myself and feed
messages down it, I guess.)
Also, the Haskell bit of Bustle is licensed under the LGPL (v2.1 or
later), but dbus-{core,client} are under the GPL v3. Could you be
convinced to reconsider the licensing of your packages? D-Bus is often
used to allow free and non-free applications to play nicely together,
letting free software be used in situations where it would otherwise be
passed over; while I for one don't plan to write any non-free D-Bus
applications in Haskell any time soon, it'd be nice not to write Haskell
off for such applications.
--
Will
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: dbus-core 0.6 and dbus-client 0.2
On Tue, Dec 8, 2009 at 16:00, Will Thompson w...@willthompson.co.uk wrote:
However, I can't find a way to feed a bytestring to dbus-core and get
back a ReceivedMessage. Is this deliberately not exposed? While it's
obviously not useful in general, it would be very useful for Bustle.
(The alternative is to construct a fake connection to myself and feed
messages down it, I guess.)
It's not exposed at the moment, because I didn't want to commit to a
public API until I knew it was going to work. When I get home tonight,
I'll add it to the API.
Aside from message marshal/unmarshal, are there any other bits of the
protocol which would be helpful to expose?
Also, the Haskell bit of Bustle is licensed under the LGPL (v2.1 or
later), but dbus-{core,client} are under the GPL v3. Could you be
convinced to reconsider the licensing of your packages? D-Bus is often
used to allow free and non-free applications to play nicely together,
letting free software be used in situations where it would otherwise be
passed over; while I for one don't plan to write any non-free D-Bus
applications in Haskell any time soon, it'd be nice not to write Haskell
off for such applications.
The following bit is just me being a free-software hippy, so take it
with a grain of salt, but:
There's already a DBus package for Haskell under the BSD 3-clause
license at http://hackage.haskell.org/package/DBus. It's a bit
awkward to use, because it's a binding to libdbus, but it exists.
dbus-core and -client offer developers ease of use in exchange for the
developers granting rights to their users.
Additionally, as far as I know, the teams porting DBus to Windows and
OS X haven't released anything stable / usable yet -- if somebody's
using DBus, it's probably on Linux, FreeBSD, etc. If any developers
want to develop proprietary software 1) for Linux/BSD 2) in Haskell 3)
using D-Bus, I'm sure both of them will take a break from rolling that
boulder uphill to ask about relicensing.
If it really is an issue -- ie, you'd be willing to use a
less-featured library to avoid the GPL -- then please reply and I'll
re-license. I don't want to negatively impact anybody else working on
free software. But I'd rather keep the license as strong as possible
until somebody actually needs it to be weakened.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: dbus-core 0.6 and dbus-client 0.2
0.7 released -- exposes the DBus.Wire module, which contains functions for marshaling and unmarshaling messages. Also supports detecting invalid UTF-8 when parsing (previously, it'd just error out). No other significant changes. https://dl.dropbox.com/u/1947532/dbus-core_0.7/index.html https://dl.dropbox.com/u/1947532/dbus-core_0.7.pdf It's difficult to know in advance how many bytes will be needed from the socket, so unmarshalMessage is written to pull them from a monad. If you're using it within pure code, you'll want to use Data.Binary.Get (or similar) to implement your parser: - import qualified Data.Binary.Get as G import qualified Data.ByteString.Lazy as BL bytes = BL.pack [1, 2, 3, 4, 5...] getBytes = G.getLazyByteString . fromIntegral received = G.runGet (unmarshalMessage getBytes) bytes - ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: dbus-core 0.6 and dbus-client 0.2
This is the second public release of my D-Bus implementation. dbus-core is an implementation of the D-Bus protocol, and dbus-client is a set of wrappers and utility computations to simplify writing basic clients. Interesting changes to dbus-core * Performance improvements: sending and receiving large structures should now be significantly faster. My thanks and appreciation go to Bryan O'Sullivan, whose excellent Criterion library made benchmarking the serialisation code much easier than it had any right to be. * Better support for byte arrays: byte strings (strict and lazy) are now directly supported types, with special cases to avoid most conversion overhead. * Implemented the TCP/IP transport, though it's untested because I can't figure out how to make the server listen on a socket. If anybody cares about remote D-Bus, and this doesn't work, drop me a mail with your configuration and I'll find out why. * Added module to represent match rules, required for full signal support. * Added module for name reservations -- this is really just moving the bulk of the code from dbus-client into dbus-core, where it belongs. * Fixed possible concurrency issue when receiving messages from a connection in multiple threads. This is still a really bad idea, and it will never work correctly, but at least now it won't corrupt the connection state. Interesting changes to dbus-client == * Fixed dumb signature to mkClient (thanks, Max). Its purpose should now be more obvious. * Shifted around some of the method call APIs -- it's now possible to send method calls without a proxy. * Uses the new MatchRule work to fully support receiving signals. Documentation = PDFs of the source; these are the most useful and complete documentation currently available: https://dl.dropbox.com/u/1947532/dbus-core_0.6.pdf https://dl.dropbox.com/u/1947532/dbus-client_0.2.pdf An API listing is also available, good for a quick overview: https://dl.dropbox.com/u/1947532/dbus-core_0.6/index.html https://dl.dropbox.com/u/1947532/dbus-client_0.2/index.html Hackage is currently experiencing some dependency conflicts with the bytestring library[1], so it's not generating its own documentation. I'll keep the dropbox pages up until Hackage is in a more usable state. Downloads = Available from the usual places: http://hackage.haskell.org/packages/archive/dbus-core/0.6/dbus-core-0.6.tar.gz http://hackage.haskell.org/packages/archive/dbus-client/0.2/dbus-client-0.2.tar.gz [1] binary uses bytestring-0.9.1.4, text uses bytestring-0.9.1.5, kaboom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
