The existing web frontends are rather clumsy and inconvenient to use.
Browsing the results of a list or search request is a good example. In
particular, when filling in (multi-)links from a search, this becomes
very evident, as the process involves clicking through a cascade of
popup windows and frames.

This could be improved with a few small additions:
The server could provide a json interface to search and query, which the
different template could then make use of with some jquery.

In message <1361809617.92.0.366547236973.issue2550797@psf.upfronthosting.co.za>
 <1361809617.92.0.366547236973.issue2550797@psf.upfronthosting.co.za>,
Stefan Seefeld writes:
>New submission from Stefan Seefeld:
>
>The existing web frontends are rather clumsy and inconvenient to use.
>Browsing the results of a list or search request is a good example. In
>particular, when filling in (multi-)links from a search, this becomes
>very evident, as the process involves clicking through a cascade of
>popup windows and frames.

Hmm, there shouldn't be any frames used at all, but I agree
autocomplete and a less heavyweight selection/display widget would be
good.

>This could be improved with a few small additions:
>The server could provide a json interface to search and query, which the
>different template could then make use of with some jquery.

I submitted an issue to develop a rest interface to accompany the
current xmlrpc interface:

  http://issues.roundup-tracker.org/issue2550734

(maybe a good GSoC project??) that would make this easier. It seems
that an xmlrpc interface is defined to always return XML
(http://xmlrpc.scripting.com/spec "The Content-Type is text/xml."),
but technically I don't see a reason that it couldn't look at the http
accept header or have a field in the xml request that defines the
response format for the payload:

  <methodResponse>
   <param>
     <value format="json">
         ....
    </value></...>

but this is probably trying to drive a nail with a screwdriver.

If alternate mechanisms for setting the fields are added, it should be
done as a progressive enhancement and not eliminate the possibility of
roundup being used with a text based browser such as elinks or
w3m. Text browsers are quite useful for a fast review/change or upload
of a file to an issue when used over ssh.

+1

FWIW I implemented an ajax autocomplete for the nosy list for
bugs.python.org in http://psf.upfronthosting.co.za/roundup/meta/issue417
(the implementation has some b.p.o-specific things, but most of the code
can be reused).

With the current work done on issue2550734 we should have a rest 
interface that can be used for exploring this idea in more detail.

Any takers?

REST interface is done.
Example selection/search using select2/jquery is documeted at:

https://wiki.roundup-tracker.org/UseSelect2andRestForIssueMultilink

Unfortunately Ezio's ajax autocomplete for the b.p.o nosy list at
http://psf.upfronthosting.co.za/roundup/meta/issue417 is a dead link.

Closing.

> Unfortunately Ezio's ajax autocomplete for the b.p.o nosy list at
> http://psf.upfronthosting.co.za/roundup/meta/issue417 is a dead link.

You can find it here: https://github.com/psf/bpo-tracker-cpython/commit/505e97ff30ab5c91813321e9bffe0c4900045fdb

Put Ezio's patch in https://wiki.roundup-
tracker.org/BugsPythonOrgJavascriptAutocompleteNosy