Change Details

I'd love some feedback on the lib api especially. this is the first REST wrapper I wrote using cpp, so it feels all a bit clunky to me. https://bugzilla.readthedocs.io/en/5.0/api/ - new internal lib wrapping the REST API - some testing on the lib, should probably be a bit more comprehensive - xmlrpc use gone - BugzillaManager continues to be a singleton manager for the API - ancient cookie system for login is entirely gone, this has been deprecated (or perhaps even removed?) for years this is functional, but still requires todo cleanups at the very least. also duplicate querying is pretty inefficient, needs porting to pagination really. some of the files are also overloaded with stuff (connection.cpp brrr) the lib api is split in three pieces: 1. the connection containing protocol logic 2. the clients containing routing logic 3. the models modeling the json blobs into cpp the clients especially feel a bit awkward, but I think separating endpoint handling from the models is a worthwhile thing. clients get a request, give back a job and the intended use is for the consumer to then connect to the finished signal of the job to then ask the clients for the final return value of the job. this is a bit 'meh'. what I really wanted was a Future to be returned and the caller to connect to the future. unfortunately qfuture is fairly limited and since qtbase has no Promise implementation I'm rather opting for the double-function-approach than doing it like we did in the previous decade and have a gazillion signals. this way the handling of the job is always uniform and all specific "handling code" is inside the connected slot rather than the actual connection. error handling has been put entirely into exceptions which get raised when trying to access a finished job. in BugzillaManager they get rescued and turned into the already existing signals. this simplifies error handling a fair amount and also makes the error handling code look uniform across the various API calls we have.

https://bugzilla.readthedocs.io/en/5.0/api/ the old API is deprecated. the new API is RESTy and much easier to use plus also has some efficiency boosts. this commit introduces a new supporting library to wrap the REST API for easy consumption in drkonqi. - new internal lib wrapping the REST API - unit testing of the lib - xmlrpc use gone - BugzillaManager continues to be a singleton manager for the API - ancient cookie system for login is entirely gone, this has been deprecated (or perhaps even removed?) for years - duplicate querying is pretty inefficient, needs porting to pagination, but is not worse than what it was before. in fact, it's faster than before out of the box! the lib api is split in three pieces: 1. the connection containing protocol logic 2. the clients containing routing logic 2.1. command models that are basically POSIX-style argument structs which can serialize into json 3. the models deserializing the json API replies back into cpp clients get a request, give back a job and the intended use is for the consumer to then connect to the finished signal of the job to then ask the clients for the final return value of the job. this is a bit 'meh'. what I really wanted was a Future to be returned and the caller to connect to the future. unfortunately qfuture is fairly limited and since qtbase has no Promise implementation I'm rather opting for the double-function-approach than doing it like we did in the previous decade and have a gazillion signals. this way the handling of the job is always uniform and all specific "handling code" is inside the connected slot rather than the actual connection. error handling has been put entirely into exceptions which get raised when trying to access a finished job. in BugzillaManager they get rescued and turned into the already existing signals. this simplifies error handling a fair amount and also makes the error handling code look uniform across the various API calls we have. the uniform representation of errors on the REST side thus always has uniform representation on the c++ side.

I'd love some feedback on https://bugzilla.readthedocs.io/en/5.0/api/ the lib api especiallyold API is deprecated. this is the first RESTthe new API is RESTy and much easier to use wrapper I wrote using cpp, so it feels all a bit clunky to meplus also has some efficiency boosts. https://bugzilla.readthedocs.io/en/5.0/api/this commit introduces a new supporting library to wrap the REST API for easy consumption in drkonqi. - new internal lib wrapping the REST API - some- unit testing onf the lib, should probably be a bit more comprehensiveb - xmlrpc use gone - BugzillaManager continues to be a singleton manager for the API - ancient cookie system for login is entirely gone, this has been deprecated (or perhaps even removed?) for years this- duplicate querying is functionalpretty inefficient, but still requires todo cleanups at the very least.needs porting to also duplicate querying is pretty inefficient pagination, needs porting to pagination really. some of the files are also overloaded with stuff (connection.cpp brrr)but is not worse than what it was before. in fact, it's faster than before out of the box! the lib api is split in three pieces: 1. the connection containing protocol logic 2. the clients containing routing logic 3. the models modeling the json blobs into cpp the clients especially feel a bit awkward,2.1. but I think separating endpointcommand models that are basically POSIX-style argument structs which can serialize into json handling from3. the models deserializing the models is a worthwhile thing.json API replies back into cpp clients get a request, give back a job and the intended use is for the consumer to then connect to the finished signal of the job to then ask the clients for the final return value of the job. this is a bit 'meh'. what I really wanted was a Future to be returned and the caller to connect to the future. unfortunately qfuture is fairly limited and since qtbase has no Promise implementation I'm rather opting for the double-function-approach than doing it like we did in the previous decade and have a gazillion signals. this way the handling of the job is always uniform and all specific "handling code" is inside the connected slot rather than the actual connection. error handling has been put entirely into exceptions which get raised when trying to access a finished job. in BugzillaManager they get rescued and turned into the already existing signals. this simplifies error handling a fair amount and also makes the error handling code look uniform across the various API calls we have. the uniform representation of errors on the REST side thus always has uniform representation on the c++ side.