Dear Maintainer, It would be great if you could add a REST api for bts with the data encapsulated in JSON. It would provide the same information as the existing soap api but it would be far more convenient to use in applications where using soap is difficult and inefficient. For instance i'm making the debian android app for gsoc 2013 and i need to query bts for various info. But for that usage soap doesn't follow the constraints of mobile computing (both in size of transmitted data and in the processing it needs afterwards) and also The "easiest" way to use soap in android is with something like kSoap2 which adds to the maintenance as an extra lib and generally complicates the development a lot. Would it be possible?
what info do you need? as a temporary solution until this is implemented in the BTS, it could be possible to do it as a UDD CGI. Lucas
More or less I would like to be able to search for bugs with the same parameters you can define here http://www.debian.org/Bugs/ So search by bug number, package name, maintainer, severity, submitters name, bug status, data (to get newest bugs). If i can also add an exclude/include argument as in the page then even better. :) I think that should be ok for now.
ok, it would be possible to implement that on top of UDD, if needed. Lucas
Would a format=json or similar argument to the existing bugreport.cgi and pkgreport.cgi pages be enough? [Or at least, the existing argument parsing.]
I think so yes. It would be equally convenient. It's an http get request anyway. :)
Hi. Pawel Sarbinowski <onexemailx@gmail.com> writes: May I suggest that you have a look at #565513 which discussed the same kind of use case. OSLC-CM is a proposed standard (now managed at OASIS) that would help make debbugs interoperable with any supporting client. Of course, OSLC-CM ranges from GET to modifying primitives for modifying bugs... so #565513 may be a bit larger spectrum than #712979. Hope this helps. Best regards,
Hi. Pawel Sarbinowski <onexemailx@gmail.com> writes: May I suggest that you have a look at #565513 which discussed the same kind of use case. OSLC-CM is a proposed standard (now managed at OASIS) that would help make debbugs interoperable with any supporting client. Of course, OSLC-CM ranges from GET to modifying primitives for modifying bugs... so #565513 may be a bit larger spectrum than #712979. Hope this helps. Best regards,
Hi. Pawel Sarbinowski <onexemailx@gmail.com> writes: May I suggest that you have a look at #565513 which discussed the same kind of use case. OSLC-CM is a proposed standard (now managed at OASIS) that would help make debbugs interoperable with any supporting client. Of course, OSLC-CM ranges from GET to modifying primitives for modifying bugs... so #565513 may be a bit larger spectrum than #712979. Hope this helps. Best regards,
Hi, I stumbled upon missing python3 soap module (cf. #732644), I looked for a workaround and found this bug report. Don mentioned [0] the possibility to have bugreport.cgi's output formated to json. Is this something available today in the bts or maybe somewhere else, maybe in UDD ? [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712979#25 Cheers, Geoff
(Moving to #712979 for the REST interface thing, and adding Bastian to recipients) On 31.12.2021 Don Armstrong wrote in #1002595: summer of code contribution? Since it is not mentioned in this bug yet - There was some discussion about this on the mailing list some time ago: https://lists.debian.org/debian-debbugs/2018/12/msg00000.html This is linked to https://github.com/venthur/debbugs-proposal There seem to be several frameworks available in Perl to build REST interfaces. Do you have any preference on which one should be used?
I'm currently working on it, but my available time is so minimal, that additional help would be welcome. My current plan is to reimplement the log and database reading pieces in python (SQLAlchemy + FastAPI) so that the number of people who can contribute to the web frontend parts is significantly larger. [I've started in on this, but it's slow going.]
Awesome news! Is there some repository to check out? I'd love to help if I can. Cheers, Bastian
Not publicly yet; I need to get more of the architecture in place before it can be reasonably collaborated on. But I hope to have it in a place that others can collaborate with me in the next 6 months or so.