|
Boost : |
From: Jeff Garland (jeff_at_[hidden])
Date: 2005-03-21 22:50:56
> Aleksey Gurtovoy wrote:
>
> > Same for a developer, actually, who usually wants to track only a
> > couple of libraries. The problem with such scheme is that it by
> > definition bumps up requirements on the reports' hosting site. Right
> > now the pages are nothing but plain HTML. Ideally, to handle the kind
> > of dynamic requests you describe in real time we need a database
> > backend, and that severely limits where the reports can be hosted. If
> > we as a group decide that the benefits of having something like this
> > outweigh the downside, this can be pulled off quite easily.
BTW, I was only suggesting this for the release results not the daily builds.
For the release the idea would be to post-process the xml data into a
pre-processed data set that could be coupled with a simple form written in
something like php to take the query and display results. That way we
wouldn't be bumping up the hosting requirements, but would be improving the
user experience. I'm certain this wouldn't be too hard to do...
On Mon, 21 Mar 2005 21:33:43 -0600, Rene Rivera wrote
> I'm not sure having such a set of dynamic result pages would help.
> It's nice to be able to answer the question of "I'm using _x_
> compiler and _y_ and _z_ libraries, does it work?". But that can
> just as easily be answered with reports that are limited to the
> platform and compiler. I've been in the situation of checking the
> results to see if what I'm using (smart_ptr, regex, spirit, threads,
> etc.) work for Linux+GCC-3.2.3. The user report I would have rather
> seen would be one that lists all the results for that one platform.
> I think that the big result grid, and the results by library only
> really help the library developers.
>
> So if we are wishing for things to happen, I'd say to change the
> user reports so that it presents single toolset results individually.
Sure that would help, but as I recall I was envisioning an 'ideal world' ;-)
Jeff
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk