> On Mon, 25 Feb 2002, Nick May wrote:
>
> > As a practical point, one issue with such a database would be speed. It
> > would be pleasantly anarchic to have a fairly promiscuous data set that
> > would mate with a range of languages. But the more one abstracts, the
> > slower things get.
Depends on how much you can preprocess content and cache it, doesn't
it? The main problem on the server side with keitai is the high
event-to-text
ratio compared to desktop web. I.e. people clicking through a lot
faster.
On the other hand, the content itself is pretty low volume. If you
prerendered all your content for every possible phone, that might
be 20x more files, but it still wouldn't be a huge amount of disk
space.
As Curt rightly points out:
> I don't think it's going to be a big problem. If we defined an XML
> format and stick the data in an XML file, most reasonable languages
> will be able to read in the data at startup and stick it in fast
> internal storage. For those that can't, you could write a standalone
> converter that would convert it into some format that would be
> easier to access (such as a Berkeley DB file or whatever).
And anyway, we're already breaking one of Knuth's laws:
"Premature optimization is the root of all evil in software design."
> My bigger concern would be devising a useful way of accessing these
> data. In particular, I'd want easy and efficient support for using
> Cocoon or other XML -> HTML/cHTML/WML/etc. translators.
I think we need to look at Juergen's breakdown and see what
we can dispense with, and where things fit.
For another view onto the problem:
At http://xml.apache.org/cocoon/ you'll find an interesting
diagram; search for 'pyramid model of contracts'. How many
of these 5 contracts are we concerned with? (Not all of them,
I hope.) The authors make much of the fact that they've
eliminated a direct logic/style interface. Is that the right
simplification for us?
-michael turner
leap@gol.com
Received on Mon Feb 25 10:21:11 2002