DBusSharp/Roadmap

From NDesk

(Difference between revisions)

Revision as of 16:46, 26 February 2007

1 Tasks remaining
2 Protocol Extensions

Tasks remaining

These are tasks planned for managed D-Bus or observations about related tools.

Thoughts from FOSDEM 07

Had the opportunity to discuss ideas with Michael Meeks (CORBA, Bonobo hacker), Simon McVittie (dbus-python)... (TODO: add others here)... These ideas came about in various conversations, but don't necessarily represent what was actually discussed (noisy venue, different terminology/language backgrounds) etc.

Robustness Principle: "Be liberal in what you accept, and conservative in what you send":

This was in relation not to the wire protocol (which should always be dealt with strictly), but with object mapping bindings etc. specifically structs (and complete messages). If additional arguments are appended to the signature, maybe we should simply discard them rather than rejecting the message. This could provide an elegant (but liberal) solution to D-Bus API versioning issues and forward compatibility. Caveat: If no error is reported, developers won't feel compelled to support issues -- but this seems to be a moot point.

D-Bus Introspection API:

Start to formalize introspection with a real standardized API to supersede XML introspection? The new API should be at its basis round-trippable to and from the legacy introspection system, and should be used only when needed so as not to break the D-Bus conceptual model. Main argument in favour of this: Applications are doing this anyway, and they're doing it in non-standard ways eg. (1) bindings that introspect before any calls in dynamic languages (2) Telepathy's "Properties" interface ties in with (3) Lack of uptake of unpopular org.freedesktop.DBus.Properties interface (4) XML does not belong in the core of a binary IPC system -- the D-Bus recursive type system already provides the functionality we need, avoiding XML library dependencies, overhead etc.

Signatures:

Is there value in formalizing convention that a Signature argument should represent a single complete type? Argument against: This goes against precedent in the header of every D-Bus message where a Signature contains multiple complete types. Arguments for: (1) The protocol already mandates a single complete type for variant signatures but does not formalize the distinction. This appears to be a violation of D-Bus' own philosophy. (2) Would (in common cases) permit an automatic GType/System.Type to/from Signature mapping, obviating the need to expose a custom Signature type in high level bindings (see Telepathy "Properties" interface for a use case) (3) (This is a more abstract argument, and not yet part of this proposal or considered a good idea) An "ag" array of Signatures in the header instead of "g" would simplify argN match rule parsing in the daemon, potentially making negative matches (the common case) faster.

org.freedesktop.DBus.Local:

Mixed feelings on this one but as we looked at the use case it looked more and more like a libdbus specific concept than an elegant pattern to be followed by other implementations/supported by bindings.

Old tasks, now completed

Built-in non-unix transports (tcp etc.)
Null variant read/write? Not possible -- daemon doesn't allow it
Test with unknown header fields to make sure we're forward compatible -- works fine
Improve exporting of .NET properties to be roundtrippable

New thoughts, February '06

Clean up Mapper.cs redundancy
Continue BusObject/Connection cleanup work
Allow exporting of static members/types? Won't be roundtrippable though
Async API: Generic AsyncResponse, or just a delegate? What's best? Perhaps identify the patterns where this is needed -- cached properties/fields etc?
The Telepathy API for example exposes Signatures in its API, but Signature was made internal during the API cleanup. Consider making this API public after review (struct or class?) or adding default marshaling for System.Type to/from signature
DType.Invalid as a \0 NULL is dangerous. Throw exceptions or handle error conditions more explicitly.

New thoughts, December '06

What happens when we call a method that will not return a message eg. F-Spot's Shutdown()?
out/ref parameter support could be a nice feature
Look into making an installable release as a matter of urgency
Update these todos to track changes up to 0.3
Look at apps to see what patterns can be formalised
Now that we can read any given signature, consider supporting marshaling of structs etc. with more members than expected, only warning if debugging is enabled. This will allow for forward compatibility of interfaces which is a pretty cool feature.

Tasks towards a pre-1.0 preview release

Marshal ObjectPath etc. as a live instance
Fix remaining obscure object mapping and transport bugs
Better checks for signature suitability
Complete internal message queues
Full thread safety (dbus-sharp was designed for thread safety but some strategic locks have still to be added and it would be better to get this right than to rush it)

Tasks towards a 1.0 release

Rewrite Message more sanely and fix ugly Wrappers code
out parameter support
Generic List support
Object path tree for introspection etc.
Finalize public API with input from .NET remoting and D-Bus experts
Run final API through fxcop, gendarme etc.
Complete GLib main loop integration API
Make sure activation works and that writing managed services is elegant

Tasks for 1.1

Full Exception support (maybe including some amount of stack trace based on contract, if this is desirable)
Build system, versioning and packaging considerations
Proper address parsing and writing if/when the spec is improved to document it fully
Optimize low hanging fruit like marshaling arrays and collections of primitives
Optimize marshaling of entirely blittable structures
Dynamic type casting and interface implementation
More?

Tasks for 1.2

Consider allowing alternatives to proxy objects for ObjectPaths, eg. taking an arbitrary delegate and registering it as a signal handler
Investigate use of LCG without any dynamic reflection
Optimize marshaling of structures which are partially blittable
Clever optimizations (scatter gather IO etc.)
Customizable object mapping based on constraints and a regular-expression style mapper

1.2 and beyond

Complete message filter engine
Daemon
Integration with other message bus systems
IronPython API to implement current dbus-python API with managed D-Bus
cilc GObject interface and proxy generator

Validation TODO

Assert at the end of reading a message that we are at the last byte of the message and there's nothing left
Assert that the signature of the marshaler matches the signature of the message

General tasks

These are tasks or thoughts that fall outside of the library itself, such as bugs found in other software during development of dbus-sharp:

Beagle may re-visit D-Bus
NetworkManager has bad D-Bus API
Banshee should expose signals for state changes now that it's easily done
Muine and Banshee may be able to share one or more common public D-Bus interface for control and management, perhaps using D-Bus work done by BMP, or MPRIS or something inspired by the UPNP media control API.
Managed hal-sharp has regressions that need debugging
Applications that may need porting: Permovi, official GPM bindings?, smuxi(?)
F-Spot could make use of hal-sharp instead of the libdbus command-line tools and a mesh of shell scripts it has now
Applications like Banshee and F-Spot currently do single instance detection with NameHasOwner. That should probably be changed to just calling RequestName with the appropriate flag (NameFlag.DoNotQueue)

Protocol Extensions

dbus-sharp embraces the D-Bus specification and extends it with certain optional additions to the D-Bus protocol. These are ifdef'd:

PROTO_REPLY_SIGNATURE

This feature is no longer enabled by default.

The signature of the MethodReply expected by a MethodCall. This is implemented as a header FieldCode:

FieldCode.ReplySignature = FieldCode.Signature + 1 = 9

It has the D-Bus type DType.Signature

Note: This may soon be renamed to FieldCode.RequestSignature to mirror FieldCode.ReplySerial.

The defined value will always be 9 and other implementations should consider this field code reserved.

PROTO_TYPE_SINGLE

This feature is enabled by default but shouldn't be used when connecting to libdbus peers.

A single precision floating point type defined by the type code 'f'.

Will not work with current libdbus dbus-daemon. Useful for peer to peer connections.

Further thoughts

Think about Decimal, DateTime, signed byte, char "primitives"

Do they deserve type codes? Look at other IPC systems for guidance.

Retrieved from "http://ndesk.org/DBusSharp/Roadmap"

 Signatures:
-Is there value in formalizing convention that a Signature argument should represent a single complete type? This goes against precedent in the header of every D-Bus message where a Signature contains multiple complete types.
+Is there value in formalizing convention that a Signature argument should represent a single complete type? Argument against: This goes against precedent in the header of every D-Bus message where a Signature contains multiple complete types. Arguments for: (1) The protocol already mandates a single complete type for variant signatures but does not formalize the distinction. This appears to be a violation of D-Bus' own philosophy. (2) Would (in common cases) permit an automatic GType/System.Type to/from Signature mapping, obviating the need to expose a custom Signature type in high level bindings (see Telepathy "Properties" interface for a use case) (3) (This is a more abstract argument, and not yet part of this proposal or considered a good idea) An "ag" array of Signatures in the header instead of "g" would simplify argN match rule parsing in the daemon, potentially making negative matches (the common case) faster.
 org.freedesktop.DBus.Local: