DBusSharp/Roadmap
From NDesk
| Revision as of 20:51, 25 October 2006 (edit) Alp (Talk | contribs) ← Previous diff |
Revision as of 09:40, 12 November 2006 (edit) (undo) Alp (Talk | contribs) Next diff → |
||
| Line 1: | Line 1: | ||
| - | |||
| === Tasks remaining === | === Tasks remaining === | ||
| Line 58: | Line 57: | ||
| * Applications that may need porting: Muine, Tomboy | * 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 | * 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 flags (NoQueue etc.) | ||
| === Protocol Extensions === | === Protocol Extensions === | ||
Revision as of 09:40, 12 November 2006
Contents |
Tasks remaining
Updated Saturday October 7 2006
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
- 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
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
- 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
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
- 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 flags (NoQueue etc.)
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.