Request #267
Extensible core
| Status: | Closed | Start date: | 06/23/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | Core & System | |||
| Target version: | - | |||
| Pull request: |
Description
Hi,
we'd like to request the extensibility of the XML-RPC server (eg. RequestManager).
Reason behind:
In our cloud system we have to support clusters that is enable users to create
clusters in one step and to query their cluster instances. If possible we'd like to
implement the feature in a clean, maintanable way that is: provide one and only one
access point for clients, hence introduce the service within the XML-RCP interface
itself.
We think that some (many?) users could benefit from the requested feature as well.
Eg. backed by the builtin extensibility of the RequestManager cloud providers
could implement their extensions specific to their environment in a clean way.
We are thinking of a simple solution 1. where extenders could register their custom
XML-RPC methods to the RequestManager and 2. which guarantees that no naming
conflict could occur.
If the request is not rejected we could submit a patch that could be used as an
initial code base later... Do you think it is possible that such feature could get
into the mainline?
Cheers,
Gyula
Associated revisions
History
#1
Updated by Ruben S. Montero about 11 years ago
Hi,
I think I do not understand this request. The idea is to allow to register a new method that will manage custom elements, is it right?. So, if you have a library (that may use or may not use the OpenNebula core libraries) that for example manages a custom element like a cluster, you would like to expose this library through the OPenNebula XML-RPC server, is that right?
Cheers
Ruben
#2
Updated by Gyula Csom about 11 years ago
Yes, that's it:) In this way we do not have to spawn new XML-RPC server instance for the custom elements/library. This makes administration easier. Also the client side can simply talk to one server instead of two. So the core would not become fragmented...
Cheers,
Gyula
#3
Updated by Ruben S. Montero about 11 years ago
Hi,
This is an interesting feature. However I do not see this happening in the 1.6 release time frame. We can go back to this after the next release.
#4
Updated by Ruben S. Montero about 8 years ago
- Status changed from New to Closed
We now have more hooks and documents class that should be enough. Other important changes should be aligned with the ACL, and quota systems... Closing