DBusSharp/Roadmap
From NDesk
| Revision as of 23:45, 2 December 2006 (edit) Alp (Talk | contribs) ← Previous diff |
Revision as of 23:05, 16 December 2006 (edit) (undo) Alp (Talk | contribs) Next diff → |
||
| Line 2: | Line 2: | ||
| These are tasks planned for [[DBusSharp | managed D-Bus]] or observations about related tools. | These are tasks planned for [[DBusSharp | managed D-Bus]] or observations about related tools. | ||
| + | |||
| + | ==== 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 | ||
| ==== Tasks towards a pre-1.0 preview release ==== | ==== Tasks towards a pre-1.0 preview release ==== | ||
Revision as of 23:05, 16 December 2006
Contents |
Tasks remaining
These are tasks planned for managed D-Bus or observations about related tools.
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
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
- 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
- Improve exporting of .NET properties
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?
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: GShare, Muine, Permovi, official GPM bindings?, last-exit
- 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.