I strongly agree that a dirt-simple DB layer would be a plus. Advanced ORMs like SQLAlchemy have their place, but are probably too much for most beginning Spyce users to handle. Most other ORMs have the kind of complexity that comes from several iterations of feature creep, without SQLAlchemy's power. There's definitely room for a tool that designs for simplicity and sticks with that design even in the face of temptation to add just one more feature. Such a tool could probably be built fairly easily on top of SQLAlchemy's introspection layer. No need to re-invent the wheel.
But, I disagree that multiple, short-lived processes is the way to go: one of the leading causes of bad PHP code is the tendency to stuff all kinds of crap into session objects, because that's the only easy way to persist things between requests. (At the extreme end of this, I've seen 10MB session blobs in the database.) A single multithreaded server simplifies this greatly, e.g. with Spyce's pool module. (Multiple, long-lived processes, of course, offer the worst of both worlds from this perspective: no state reset between requests, AND no simple persistence -- because your user might not get the same process with his next request.) Scalability is a separate problem, really; by the time you have more traffic than you can handle with a single threaded server, you should either have a clue or be able to hire someone who does. :)
(Amusing captcha, btw. :)
A multiprocess server isn't so much about performance, it's about reliability and some better predictability (not perfect if you aren't throwing away all state, but at least better). And in part about architecture. Putting stuff into a session isn't particularly worse than putting stuff into a global variable. Better, really; at least you are being explicit about the storage you are doing. I already abhor losing any information on server restart -- I always regret it later -- so I don't put anything valuable in memory. If it's too hard to do otherwise, then that is something to be fixed, it's not that we should use the poor man's persistence of threading and global state.# Ian Bicking
"I already abhor losing any information on server restart -- I always regret it later -- so I don't put anything valuable in memory."
For my applications, there always seems to be all kinds of temporary crap that I'd like in memory to avoid recomputing, but that I can always auto-re-derive from my normalized data on a restart. I guess either we're writing different kinds of apps, or we're not really disagreeing, or a little of both -- what I keep in memory isn't "valuable," either, but I do enough of it that if the only caching API I had were a session-based one, my code would suck.
(This isn't really about premature optimization, either; I could point at any number of pages where doing a dozen queries to set things up once a day or once a server restart is okay, but doing it once per page load is unacceptable with any number of users.)