[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: debbugs.el

From: Evgeny M. Zubok
Subject: Re: debbugs.el
Date: Fri, 25 Feb 2011 19:51:29 +0300
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Michael Albinus <address@hidden> writes:

>> One year old screenshot:
>> http://s006.radikal.ru/i214/1001/d1/08ef5f85246e.png
> That includes both frontend and backend. For better exploitation,
> debbugs.el is intended to offer backend functionality only, it does
> not care about any UI.

> I've also written a frontend similar to what you have done, but it is
> based on widgets instead of outline mode. Like yours, it is
> unfinished.

My solution is also have a layered architecture: (i) a separate package
with generic SOAP client library; (ii) a separate package with
debbugs-soap.el as backend; (iii) debian-bts mode as a frontend. One of
my initial design consideration was to allow custom
frontends. debbugs-soap.el backend is very small library. It only
performs the requests to Debbugs server such as: get_bugs, get_status,
get_versions, get_bug_log, etc. All mbox functionality currently
implemented in frontend. I think it's a good idea to move it into
backend as alternative (to SOAP) method of receiving logs from server.

> That's how I also started mid of 2009. Last year, I switched to
> soap-client.el (recently added to Emacs' trunk). My code is much less
> ugly now.

This library appeared at the same time with my library. I was going to
prepare my soap-client.el for Emacs but someone is way faster than
me. :) Well, I will help soap-client.el from 'trunk' with patches. :)

>> I want to start hacking again and hope to finish it some day. :)
> Let's do  it together. We  could merge the backend  functionality into
> debbugs.el, and continue to work on the different frontends. As I have
> said already, I would also be interested in an nnir integration.

Is your project published somewhere?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]