[RC5] Stats RSS Feed?

Ben Gavin thejet at gmail.com
Fri Jan 7 17:46:19 EST 2005

On Fri, 7 Jan 2005 16:07:43 -0600, Jim C. Nasby <decibel at distributed.net> wrote:
> On Thu, Jan 06, 2005 at 11:12:06AM -0600, Ben Gavin wrote:
> > Of course, if we go XML for everything, then we need to figure out
> > some way of getting XML out of the database layer itself [without an
> > intervening PHP page], or we're introducing an XML translation step
> > for every page in the system, which is probably sub-optimal [even with
> > caching of the XML output].  I don't know that PostgreSQL has an XML
> > output method, so this may not be an option at this time.  We've
> > already got classes which generate all the lists we need, so maybe
> > introducing the XML step for everything at this time is a bad idea...
> I'm not sure why you feel this is the case. There's no reason we can't
> use PHP or Java or what-have-you as a middle-tier that talks to the
> database and generates XML data. This XML data could then be converted
> into any format we needed.

Right, and I agree with you that eventually it would be nice to get
there [after all, I suggested it eons ago ;), and I probably wasn't
the first ], however the point has been brought up before, and I think
it still has merit, that we're basically introducing another
translation layer for rather minimal [in the end] gain.  If we were
able to get the translation costs minimized to be negligible as
compared to the total page processing cost, then I'd say we should go
that direction.  However, I've been involved in a number of projects
that utilized an XML based middle-tier, and unfortunately a number of
times we had to pay a pretty significant price to generate that XML
from the underlying dataset.

We also talked about caching once upon a time, and implementing
caching [at the expense of disk space] would certainly go a long way
toward amortizing the XML creation costs across many page views, and
probably make either solution equally performant.

I guess my point was that since we've already got the data access
pieces abstracted into the various classes, that we don't gain a
_whole lot_ by going all the way to XML for everything, since the
logic to produce the PHP pages based on the classes is pretty lean in
and of itself, so it becomes a question of whether we can better
support PHP code or XSLT code...  If there is significant pushback
from our users or developers against the XSLT concept, we wouldn't be
giving up too much by just falling back onto straight PHP.

In either cases, discussions such as this probably belong in stats-dev
rather than on the main RC5 list ;)


Benjamin Gavin
virtual.olympus software
ben at virtual-olympus.com

More information about the rc5 mailing list