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.