localoutline

It was a very heads-down weekend.
We delivered a new server-side architecture for Frontier 5 called Betty. It was developed by a brilliant University of Texas undergrad named Wesley Felter. Wes works for UserLand between classes and mid-term exams. In the middle of last week he shared something that he had been developing on the side, something he called TinkerToy.
TinkerToy is a shell around a server app he's writing to support the IETF WebDAV protocol, a very important workflow process that's essential in doing content management on a network. It turned out that the shell was even more interesting than the WebDAV responder, so he dug in and built some other kinds of responders. Wes did all this on the side, we didn't know he was doing it!
It turned my world upside down. Instead of assuming that Frontier gets all its HTTP requests thru web server software like IIS, Apache, Netscape or WebSTAR, he assumed that Frontier is doing all the work, and let his creativity flow from there.
When I saw what he had done, I wanted to ship it immediately so we could start building compatible protocol handlers in Frontier alongside our developers and users.
***Betty
We have a server running on our LAN here at betty.userland.com. It's our testbed for new server-side functionality. Betty is a 200 Mhz, 64 MB, Pentium II running Windows NT Workstation 4.0. Not exactly a honker these days, but still quite useful.
I didn't like the name TinkerToy, it's too diminutive, so we changed to Betty, naming it after the machine we were deploying on.
Then we released the software thru a new website, with pointers to the experiments that were running on the Betty server. Dynamic page rendering, web-based remote admin, XML-based RPC, and many other neat things that were awkward in the past, became simple. We documented, tested, explained, fixed bugs... it was a very furious pace!
http://www.scripting.com/frontier5/betty/whatIsBetty.html
Now the dust is starting to settle, and I realize that we got somewhere I've wanted to be for a long time.
***A bolt of lightning!
A longtime Frontier developer, Ed Draper, who now is at Compaq, asked a simple question last night on the Frontier-central list.
"Can Betty render 500 pages a minute?"
Gulp! It's a shocking but fair question. I have no idea. No, I don't think it can.
I took that problem to bed with me last night, and this morning I have the answer.
It doesn't matter. The server-side dynamic page rendering isn't as important as client-side rendering because now the server can be distributed.
That must sound like a puzzling statement. But it's a puzzling new situation.
Here's the logic.
***New logic
Frontier is now a web server. What does that mean?
By definition, that means that web browsers can now talk directly to us. We've had some of that working before thru a method called protocol handlers, but they weren't implemented well on the Mac, so we never were able to build features in Frontier behind it .
But there's no problem, on Mac or Windows, with a web browser talking to a web server. That's what they were designed to do! If they don't do that well, then they can't claim to be a browser.
***Bonk!
So, why would anyone care about this, other than people who geek around inside servers?
Because it all can work on a client or content development machine. The browser can talk directly to us. That means we can build friendly user interfaces on data that's stored in our object database; all the websites, system scripts, everything.
And how does the information flow into the database? Thru the web server, using XML-based RPC, whatever format turns out to be the standard, the more the merrier.
Now we can think of client-side and server-side being exactly the same thing. Content that lives well in either place. Data moves around via XML RPC. Smart sandboxes. Powerful rendering anywhere.
I've been writing about this for years. Now we're there.
I'm so excited!
Dave Winer
PS: I know this is over almost everybody's head. But we crossed a major milestone and I want people who grok the technology to understand where we are.
PPS: DHTML is the next area we dig into.
PPPS: Of course we still do powerful and elegant statically rendered websites.