Hide Forgot
Description of problem: Currently we use kobo for 99% of command line communication to the Scheduler, This bug is to investigate if moving to Rest(JSON) interface would be faster and simpler. Currently Every method has to be duplicated in TG to support xmlrpc. Rest(Json) support is built into TG and would not require separate methods. Could kobo be extended to support Rest(Json) as well as xmlrpc?
(In reply to comment #0) > Description of problem: > Currently we use kobo for 99% of command line communication to the Scheduler, > This bug is to investigate if moving to Rest(JSON) interface would be faster > and simpler. > > Currently Every method has to be duplicated in TG to support xmlrpc. If it has to be duplicated it's possibly because we aren't doing it right in the first place. i.e we should have methods that just return the data needed, and the controllers can dress the data as they like. > Rest(Json) support is built into TG and would not require separate methods. I'm not too clear on this. We would still need to structure our controllers and methods properly to support REST. And yes, TG can expose the methods as JSON for us. > > Could kobo be extended to support Rest(Json) as well as xmlrpc?
(In reply to comment #1) > (In reply to comment #0) > > Description of problem: > > Currently we use kobo for 99% of command line communication to the Scheduler, > > This bug is to investigate if moving to Rest(JSON) interface would be faster > > and simpler. > > > > Currently Every method has to be duplicated in TG to support xmlrpc. > > If it has to be duplicated it's possibly because we aren't doing it right in > the first place. > i.e we should have methods that just return the data needed, and the > controllers can dress the data as they like. > > > Rest(Json) support is built into TG and would not require separate methods. > > I'm not too clear on this. We would still need to structure our controllers and > methods properly to support REST. And yes, TG can expose the methods as JSON > for us. I could be wrong but I thought it was as simple as adding @expose(“json”) to any of the existing templates. > > > > > Could kobo be extended to support Rest(Json) as well as xmlrpc?
(In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > Description of problem: > > > Currently we use kobo for 99% of command line communication to the Scheduler, > > > This bug is to investigate if moving to Rest(JSON) interface would be faster > > > and simpler. > > > > > > Currently Every method has to be duplicated in TG to support xmlrpc. > > > > If it has to be duplicated it's possibly because we aren't doing it right in > > the first place. > > i.e we should have methods that just return the data needed, and the > > controllers can dress the data as they like. > > > > > Rest(Json) support is built into TG and would not require separate methods. > > > > I'm not too clear on this. We would still need to structure our controllers and > > methods properly to support REST. And yes, TG can expose the methods as JSON > > for us. > > I could be wrong but I thought it was as simple as adding > > @expose(“json”) > I think that's right, except you can only (and you would only want to) serialize a restricted set of data types. So you couldn't @expose("json") bkr.server.model:Root.new() > to any of the existing templates. > > > > > > > > > Could kobo be extended to support Rest(Json) as well as xmlrpc?
AFAIK we no longer care about this.