-
Notifications
You must be signed in to change notification settings - Fork 2
GSoC:2008 Service Clients and Language Bindings Milestones
Erik Massop edited this page Nov 4, 2017
·
1 revision
- Hooray!
- 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.
- 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.
- See 1 and 2 for details.
- 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.
- Use the new SC API.
- Appease the Merge Gods with sacrifices.
Content is available under GNU Free Documentation License 1.2 unless otherwise noted.
- Community
- Development