Main Page DBusSharp/Roadmap

From NDesk

Jump to: navigation, search

Contents

Tasks remaining

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

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
  • Test the new generated iface IL, make it throw exceptions in the problem method itself, check for nulls etc.
  • 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)
  • Finalize public API with input from .NET remoting and D-Bus experts
  • Run final API through fxcop, gendarme etc.
  • Make sure activation works and that writing managed services is elegant
  • Mono JIT broken for 0.5.x on ARM (Now fixed, https://bugzilla.novell.com/show_bug.cgi?id=322722#c2)

New thoughts

  • Bug: Conflicting type names when the same D-Bus interface has multiple managed interfaces to be proxied (eg. multiple hal-sharp libraries in use by Banshee)
  • Bug: Large messages. Fix is available.
  • Feature: Object mapping. Patch is available.
  • Anonymous interface support? Method calls with no iface specified.
  • Complete out parameter support
  • Named pipe backend

Recent thoughts

  • Ability to "export" a large number of virtual objects eg. music tracks, photos or spreadsheet cells?
  • CodeDom output from introspection data
  • DLR integration
  • More extensive test suite for inherited exported events
  • Native double may have words swapped (on ARM)? See Mono new DataConverter. Investigate.
  • Add validation for type depth, signatures and names
  • Make use of the D-Bus address guid part rather than ignoring it
  • Consider implementing authentication key stuff
  • Mono bug #78592: ExactBinding is igonred by Type.GetMethod breaks 0.5 and greater on old Mono versions
  • Assembly permissions broken with generated IL on MS .NET
  • Non-blocking IO
  • 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.
  • Move to UTF-8/ASCII internal string representation where possible

New thoughts, December '06

  • What happens when we call a method that will not return a message eg. F-Spot's Shutdown()? Maybe inherit CriticalFinalizerObject (or use SafeHandle?) to ensure that a reply token is sent, or an error if return values were expected
  • out/ref parameter support could be a nice feature
  • Treat params arrays as having a variable signature on the wire?
  • 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


Tasks towards a 1.0 release

  • Introduce new class-based message read/write system, this should make write IL generation easy and work around only recently-fixed Mono StrictBinding bug
  • Rewrite Message more sanely and fix ugly Wrappers code
  • Generic List support
  • Object path tree for introspection etc.
  • Complete GLib main loop integration API

Tasks for 1.1

  • Full Exception support (maybe including some amount of stack trace based on contract, if this is desirable)
  • ProtocolException and subclasses that will dump the message body and error offset if DBUS_VERBOSE is set
  • 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 "https://ndesk.org/DBusSharp/Roadmap"