summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDavid Zeuthen <davidz@redhat.com>2010-04-30 10:42:46 -0400
committerDavid Zeuthen <davidz@redhat.com>2010-04-30 10:42:46 -0400
commitfd981112644d9709f6ecaa66278a189be897dc04 (patch)
tree6d03a28dc7aeda9ceb18dd7c393f83e0bd52db40
parent92a1663d1fdd4e6856af59663cddf21846b36da7 (diff)
Start keeping a TODO list
-rw-r--r--gdbus/gdbusconnection.c68
1 files changed, 68 insertions, 0 deletions
diff --git a/gdbus/gdbusconnection.c b/gdbus/gdbusconnection.c
index 10b2ec4..b4a272e 100644
--- a/gdbus/gdbusconnection.c
+++ b/gdbus/gdbusconnection.c
@@ -20,6 +20,74 @@
* Author: David Zeuthen <davidz@redhat.com>
*/
+/*
+ * TODO for GDBus:
+ *
+ * - would be nice to expose GDBusAuthMechanism and an extension point
+ *
+ * - need to expose an extension point for resolving D-Bus address and
+ * turning them into GIOStream objects. This will allow us to implement
+ * e.g. X11 D-Bus transports without dlopen()'ing or linking against
+ * libX11 from libgio.
+ * - see g_dbus_address_connect() in gdbusaddress.c
+ *
+ * - Do we need a way to get the authenticated user like e.g.
+ *
+ * - dbus_connection_get_is_authenticated()
+ * - dbus_connection_get_is_anonymous()
+ * - dbus_connection_get_unix_user()
+ * - dbus_connection_get_windows_user()
+ *
+ * We could have a GCredentials class and maybe GUnixCredentials
+ * and GWin32Credentials subclasses.. or (better) just the one
+ * GCredentials class with methods
+ *
+ * - get|set_pid(),
+ * - get|set_unix_uid(),
+ * - get|set_unix_gid()
+ * - get|set_selinux_context()
+ * - get|set_win32_sid()
+ * - ...
+ *
+ * including a way to "unset" a certain credential. Then we'd have
+ *
+ * - GCredentials new_for_current_process()
+ * - bool same_user()
+ * - bool are_superset()
+ *
+ * e.g. basically the DBusCredentials class from libdbus.
+ *
+ * We'd also use this in GUnixCredentialMessage. Remember that credentials
+ * on various UNIX platforms can be more than just the (pid, uid, gid)
+ * tupple that Linux supports.
+ *
+ * - Do we need something like GDBusServer? Meh, see tests/peer.c
+ * for how it's really simple if you know the transport already. OTOH,
+ * given a D-Bus address for servers means that e.g. X11 transports
+ * won't really work well. We could have a very simple API like
+ * this
+ *
+ * typedef enum {
+ * G_DBUS_SERVER_FLAGS_NONE = 0,
+ * G_DBUS_SERVER_FLAGS_RUN_IN_THREAD = (1<<0),
+ * } GDBusServerFlags;
+ *
+ * typedef void (*GDBusServerNewConnectionCallback) (GDBusConnection *connection,
+ * gpointer user_data);
+ *
+ * GDBusServer *g_dbus_server_new (const gchar *dbus_address,
+ * const gchar *guid,
+ * GDBusServerFlags flags,
+ * GDBusServerConnectionAcquiredCallback new_connection_handler,
+ * gpointer user_data,
+ * GError **error);
+ *
+ * or similar. If we start seeing lots of pluggable transports it might
+ * make sense to do this. If we don't, it's probably fine with just
+ * requiring users to do what we're doing in tests/peer.c
+ *
+ */
+
#include "config.h"
#include <stdlib.h>