DBusSharp/Roadmap

From NDesk

---

Revision as of 20:51, 25 October 2006

Contents 1 Tasks remaining 1.1 Tasks towards a pre-1.0 preview release 1.2 Tasks towards a 1.0 release 1.3 Tasks for 1.1 1.4 Tasks for 1.2 1.5 1.2 and beyond 1.6 General tasks 2 Protocol Extensions 2.1 PROTO_REPLY_SIGNATURE 2.2 PROTO_TYPE_SINGLE 2.3 Further thoughts

[edit] Tasks remaining

Updated Saturday October 7 2006

[edit] 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)

[edit] Tasks towards a 1.0 release

• out parameter support
• Generic List support
• Non-native endian message 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

[edit] 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
• Built-in non-unix transports (tcp etc.)
• Dynamic type casting and interface implementation
• More?

[edit] Tasks for 1.2

• 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

[edit] 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

[edit] 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:

• 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
• Managed hal-sharp has regressions that need debugging
• Applications that may need porting: Muine, Tomboy
• F-Spot could make use of hal-sharp instead of the libdbus command-line tools and a mesh of shell scripts it has now

[edit] 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:

[edit] 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.

[edit] 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.

[edit] Further thoughts

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

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