GSoC:2008 Service Clients and Language Bindings Milestones - nesciens/xmms2-wiki GitHub Wiki
Student Accepted
Hooray!
Result/Value Split
This must be done before service clients (SC) work can begin. See 1835.
The current SC code is based on a partial, workable implementation of the result/value split. Development on the split is being done concurrently by theefer now.
Bang Out New API
Services are registered as a whole, not method-by-method.
Service methods will use the new xmmsc_value_t where applicable instead of using xmmsc_result_t.
No need to provide remove/unset functionality as services will provide static functionality.
Previously, a service was referenced by its name and methods were registered directly to the server.
Now, methods are added to a service all on the client-side, then sent to the server as one.
This has a more logical flow as well as providing some API benefits:
Methods are registered exactly once at the time of service registration. They cannot be registered after a service is already registered, guaranteeing that clients can always use given service methods.
Argument type-checking and similar error checking is done client-side rather than by straining the server. The server is only responsible for passing requests back and forth between service and normal client.
A service is referenced by its originating connection. Before, service methods each stored an xmmsc_connection_t, which meant a service could register methods from different connections--probably not a good idea.