Easy Publish and Consume Library
As GNOME remembers the meaning of the 'N' in its name, more and more GNOME applications become network aware. GNOME provides excellent libraries for implementing network capabilities, nevertheless quite some effort is needed to glue them together to provide a smooth user experience.
When starting to add network support to Glom, we at Openismus decided it would be time to stop this frequent reinvention of the wheel, and put some of this glue code into an easy to use library. So the Easy Publish and Consume Library (libepc) was born.
The Easy Publish and Consume Library is intended to provide an easy method to
- publish data per HTTPS
- announce that information via DNS-SD,
- find that information
- and finally consume it
When using that library you shall not bother about boring details like properly using Avahi or setting up SSL/TLS certificates. All you should do to let your application publish information to the network, is writing the following three commands:
publisher = epc_publisher_new ("Easy Publisher Example", NULL, NULL);
epc_publisher_add (publisher, "Hello", "World!", -1);
epc_publisher_run_async ();
Once you have done this, your application runs a HTTPS server, announcing itself to the local network via DNS-SD and publishes the information World! under the key Hello.
Retrieving values shouldn't be harder:
consumer = epc_consumer_new_for_name ("Easy Publisher Example");
value = epc_consumer_lookup (consumer, "Hello", &length, &error);
As those examples are working now, we Openismus guys would highly welcome some feedback - I even added e-mail notifications to my site to allow real discussion.
Well, maybe it should be noted, that libepc isn't meant to replace desktop configuration daemons like GConf or Ryan's dconf initiative. This library just is a simple method for publishing byte arrays and maybe UTF-8 strings to your network. No support for integers, booleans, no schemas. It's fully up to you, how to use the data published.
- Source code is available: git clone http://taschenorakel.de/git/libepc
- Alternatively you can get tarballs: libepc-0.2.tar.bz2 (Signature), git snapshots
- Maybe more important at this stage: The Reference Manual
- And code examples: list-resources.c, lookup-resource.c, simple-publisher.c, consumer-ui.c
This locations at taschenorakel.de are just temporary locations, if nobody disagrees I'd like to upload this library to the GNOME servers as soon as possible.
Oooh, very interesting.
Any examples of what cool things it could be used for would certainly help it being adopted. Right now, I don't see anything interesting over using Avahi directly, especially when creating a new service.
See also local-export-daemon,
http://svn.mugshot.org/local-export-d...
http://log.ometer.com/2007-06.html#23.3
Same idea but uses a single dbus server rather than per-app http server. And no crypto, I guess. (But since there's no auth for local-export-daemon, the crypto doesn't matter much, since anyone can connect anyway.)
s/DNS-DS/DNS-SD/
Bastien, avahi just lets you publish and find the service. This does that (via avahi, but more simply), and actually provides the network service and client to use what you've found.
We'll be using it in Glom so that Glom clients can connect to other Glom instances and open their Glom documents over the network.
Havoc, yes, we saw that, but we wanted something simpler and self-contained.
Havoc: As you might have figured on IRC, I was playing with D-Bus initially. It is good stuff, but D-Bus absolutly isn't designed for network usage. Yes, it offers a TCP/IP transport, but as you mentioned already there is no encryption, and there is no remote authentication[1].
So instead of re-inventing the wheel by glueing D-Bus with gnutls and implementing for instance digest authentication, we have choosen to be good engineers, and placed our code on top of existing code (libsoup, Avahi) which has the features we need: Networking, encryption, remote authentication.
[1] Authentication in D-Bus isn't based on username/password tokens, but on local user or process ids. The reasoning behind using surrogate keys (user ids), instead of the real primary key (user name) is absolutly beyond my scope. Specially when you look at the code uglyness it causes for instance, when trying Windows support.
Bastien: It makes me quite speechless, that you are not impressed by seeing the entire HTTPS and Avahi setup code to one single statement:
publisher = epc_publisher_new ("Easy Publisher Example", NULL, NULL);
Incomplete and inrobust service publication takes about 200 lines of code with AvahiClient (http://avahi.org/browser/trunk/exampl...). EpcDispatcher, which should be more robust and developer friendly, even needs 450 lines of code: http://taschenorakel.de/gitweb/?p=lib...
Creating and reusing self-signed certificates also isn't trivial: http://taschenorakel.de/gitweb/?p=lib...
>Bastien: It makes me quite speechless, that you
>are not impressed by seeing the entire HTTPS
>and Avahi setup code to one single statement:
I do am really impressed, this is the kind of api that permits the normal developer to do rapid development, these are the apis that incentivates doing applications.
Mathias, I wasn't impressed before as you didn't explain what this library did properly. To me, it looked more or less like bolting on random (small) data onto an Avahi record.
Checking sender address for blog notifications: Quite some mail servers do not like "webmaster@localhost".