Stefano Zacchiroli wrote, Thursday, February 14, 2008 7:50 AM
On Wed, Feb 13, 2008 at 10:57:24PM +0000, Adam D. Barratt wrote:
>
> > * show/bugs clearly should work offline, but in that case we are
> > anyhow
> > showing either an HTML page or a mailbox, so it isn't really related
> > to SOAP or scarping HTML, since in one of the two cases the HTML is
> > actually the final target of our action
[...]
Wonderful and thanks for the detailed info, but ... well, this does not
defeat my point: it is anyhow stuff that you won't get using the SOAP
interface anyhow, it is mostly presentational stuff.
So I continue not seeing the tension between offline mode and porting
bts to the SOAP interface: the offline mode can stay there, while the
online mode will use soap.
[Apologies if any of the below sounds "egg sucky", I'm just being verbose
:-)]
The main issue is that if one ignores the on disk cache (which is used in
both online and offline modes), I'm not sure which current functionality
could usefully be modified to use SOAP without duplicating operations.
The primary difference between online and offline modes is that the online
mode updates the cache as it works, whereas offline mode displays the
previously cached copies. By way of an example, bts show/bugs/cache
devscripts all download the devscripts binary package bugs index, cache a
mangled copy and, in the case of show/bugs, display the page to the user.
bts cache then continues by parsing the cached file to extract the list of
bugs it contains and downloads each in turn, caching and mangling as it
progresses. Whilst the first step could be replaced by a call to select(),
we still need to download and mangle the HTML in order for it to be either
used offline or stored locally for future use. Adding SOAP support would
therefore only remove one parsing step - extracting the list of bugs from
the HTML. The caching process still ties us to the structure of the HTML in
order to perform the mangling process.
In summary, I don't see the benefit of replacing the initial bug selection
step with a SOAP call when all the interesting (imho) functionality that
follows from that step is still reliant on parsing the HTML for e.g.
attachments, links to other bugs. #429236, #460301, #460850 and #414200 (for
a few I found quickly) all occured due to HTML changes and I can't see any
way we could have avoided them.
Adam
--
To unsubscribe, send mail to [EMAIL PROTECTED]
