<table><tr><td style="">sitter created this revision.<br />Herald added a project: Plasma.<br />Herald added a subscriber: plasma-devel.<br />sitter requested review of this revision.

</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D19612">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>I'd love some feedback on the lib api especially. this is the first REST<br />

wrapper I wrote using cpp, so it feels all a bit clunky to me.</p>

<p><a href="https://bugzilla.readthedocs.io/en/5.0/api/" class="remarkup-link" target="_blank" rel="noreferrer">https://bugzilla.readthedocs.io/en/5.0/api/</a></p>

<ul class="remarkup-list">

<li class="remarkup-list-item">new internal lib wrapping the REST API</li>

<li class="remarkup-list-item">some testing on the lib, should probably be a bit more comprehensive</li>

<li class="remarkup-list-item">xmlrpc use gone</li>

<li class="remarkup-list-item">BugzillaManager continues to be a singleton manager for the API</li>

<li class="remarkup-list-item">ancient cookie system for login is entirely gone, this has been deprecated (or perhaps even removed?) for years</li>

</ul>

<p>this is functional, but still requires todo cleanups at the very least.<br />

also duplicate querying is pretty inefficient, needs porting to pagination<br />

really.</p>

<p>some of the files are also overloaded with stuff (connection.cpp brrr)</p>

<p>the lib api is split in three pieces:</p>

<ol class="remarkup-list">

<li class="remarkup-list-item">the connection containing protocol logic</li>

<li class="remarkup-list-item">the clients containing routing logic</li>

<li class="remarkup-list-item">the models modeling the json blobs into cpp</li>

</ol>

<p>the clients especially feel a bit awkward, but I think separating endpoint<br />

handling from the models is a worthwhile thing.</p>

<p>clients get a request, give back a job and the intended use is for<br />

the consumer to then connect to the finished signal of the job to then<br />

ask the clients for the final return value of the job.<br />

this is a bit 'meh'. what I really wanted was a Future to be returned<br />

and the caller to connect to the future. unfortunately qfuture is fairly<br />

limited and since qtbase has no Promise implementation I'm rather opting<br />

for the double-function-approach than doing it like we did in the previous<br />

decade and have a gazillion signals.<br />

this way the handling of the job is always uniform and all specific<br />

"handling code" is inside the connected slot rather than the actual<br />

connection.</p>

<p>error handling has been put entirely into exceptions which get raised<br />

when trying to access a finished job. in BugzillaManager they get rescued<br />

and turned into the already existing signals. this simplifies error<br />

handling a fair amount and also makes the error handling code<br />

look uniform across the various API calls we have.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R871 DrKonqi</div></div></div><br /><div><strong>BRANCH</strong><div><div>master</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D19612">https://phabricator.kde.org/D19612</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>CMakeLists.txt<br />

src/CMakeLists.txt<br />

src/bugzillaintegration/bugzillalib.cpp<br />

src/bugzillaintegration/bugzillalib.h<br />

src/bugzillaintegration/duplicatefinderjob.cpp<br />

src/bugzillaintegration/duplicatefinderjob.h<br />

src/bugzillaintegration/libbugzilla/CMakeLists.txt<br />

src/bugzillaintegration/libbugzilla/attachment.cpp<br />

src/bugzillaintegration/libbugzilla/attachment.h<br />

src/bugzillaintegration/libbugzilla/autotests/CMakeLists.txt<br />

src/bugzillaintegration/libbugzilla/autotests/bugtest.cpp<br />

src/bugzillaintegration/libbugzilla/autotests/bugzillatest.cpp<br />

src/bugzillaintegration/libbugzilla/autotests/connectiontest.cpp<br />

src/bugzillaintegration/libbugzilla/autotests/data/bugs.dragonplayer.json<br />

src/bugzillaintegration/libbugzilla/autotests/data/error.http<br />

src/bugzillaintegration/libbugzilla/autotests/data/hi.http<br />

src/bugzillaintegration/libbugzilla/autotests/data/product.dragonplayer.json<br />

src/bugzillaintegration/libbugzilla/autotests/data/put.http<br />

src/bugzillaintegration/libbugzilla/autotests/producttest.cpp<br />

src/bugzillaintegration/libbugzilla/bug.cpp<br />

src/bugzillaintegration/libbugzilla/bug.h<br />

src/bugzillaintegration/libbugzilla/bugzilla.cpp<br />

src/bugzillaintegration/libbugzilla/bugzilla.h<br />

src/bugzillaintegration/libbugzilla/comment.cpp<br />

src/bugzillaintegration/libbugzilla/comment.h<br />

src/bugzillaintegration/libbugzilla/connection.cpp<br />

src/bugzillaintegration/libbugzilla/connection.h<br />

src/bugzillaintegration/libbugzilla/product.cpp<br />

src/bugzillaintegration/libbugzilla/product.h<br />

src/bugzillaintegration/parsebugbacktraces.cpp<br />

src/bugzillaintegration/parsebugbacktraces.h<br />

src/bugzillaintegration/productmapping.cpp<br />

src/bugzillaintegration/productmapping.h<br />

src/bugzillaintegration/reportassistantpages_base.cpp<br />

src/bugzillaintegration/reportassistantpages_bugzilla.cpp<br />

src/bugzillaintegration/reportassistantpages_bugzilla.h<br />

src/bugzillaintegration/reportassistantpages_bugzilla_duplicates.cpp<br />

src/bugzillaintegration/reportassistantpages_bugzilla_duplicates.h<br />

src/bugzillaintegration/reportinterface.cpp<br />

src/bugzillaintegration/reportinterface.h<br />

src/drkonqi.cpp</div></div></div><br /><div><strong>To: </strong>sitter<br /><strong>Cc: </strong>plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart<br /></div>