Betty: Early April Coming-Together
If you're part of the Betty process, here's how things are changing.
There are four big tables in the release: builtins.webserver, builtins.xml, builtins.betty and the responders table. A few other small pieces are included but these four places are the big ones.
The big goal is 5.0.2
We're rolling things up one level. builtins.xml is now merged with the Betty flow. We'll iterate over the stuff, and then when it's ready, roll Betty into the root updates process. When that's solid and the kernel has caught up, we'll release a final 5.0.2.
That should give people a breather while we dig in on the next series of features and performance enhancements.
A major improvement in the RPC responder.
It can now handle tables and lists both as parameters and returned results. A complete error reporting mechanism is implemented. And the format has changed to offer more opportunity for compatibility with servers implemented in other environments and on other operating systems.
The change is so deep that we call the new responder RPC2. That leaves the door open for RPC3 and 4 and so on. But the interface up from the RPC mechanism shouldn't change from here-out.
It requires 5.0.2b6 or greater
Frontier 5.0.2b6 is required because betty.rpc.server calls a new kernel verb, callScript.
If you're a Frontier system-level implementor, after installing, check out betty.rpc.server to see how it calls the new callScript built-in verb.
This new connection makes it possible to build fully powerful servers entirely in scripts. This interface used to be locked up behind the family of appleEvent builtin verbs. Now it comes out of hiding.
There are a handful of people whose software could get more powerful because of this new verb.
The rest of this page walks you thru the changes. If you're writing code in the new environment, please read this carefully. There's a lot of info on this page.
builtins.betty gets some organization and gets some new functionality
loadScriptingNews goes into the new betty.experiments table. It's not coded to the current builtins.xml interface, and there are problems running HTML code thru the XML compiler.
suites.remoteAdmin.plainForm moves to betty.macros.handleForm. websites.bettyDynamicSite is updated to call the macro in its new location.
BTW, since all builtins can be referred to without the builtins part of the address, I'm going to drop that part in the rest of this story.
betty.rpc.server is called from the new RPC2 responder (details below). It implements and documents the new format we're using for XML-based messaging. This is finished code. Test it. Let's be sure it's right.
betty.rpc.client is low-level code, it will soon be replaced by the beautiful client interface that Doug is working on.
But the low-level betty.rpc.client interface will have a purpose even after the beautiful interface ships. If you want to debug a conversation, drop down to this level, and save copies of the XML text that's transmitted and received. It's saved my ass a few times.
It calls betty.init, which creates a user.betty table and user.betty.rpcHandlers.
Assuming that webserver.init has been run and that there is a responders table, betty.install adds a table of handlers at user.betty.rpcHandlers.examples, for testing your setup.
These handlers are called by the RPC2 responder thru betty.rpc.server.
You don't have to call betty.install, workspace.bettyNewParts.Installer calls it.
These scripts are used in testing our Betty setup and you can use them too, to be sure everything's in the right place and working.
The first test you should run is betty.examples.localTest.test. It should show a dialog with the names of four states.
Then run betty.examples.faultTest.test. It should display an Error Info window saying that the server doesn't know about wild beatnik pie.
We'll add more examples that show how to pass tables and lists across this interface.
A new table containing two scripts, frontierValueToTaggedText and structToFrontierValue. These scripts are low-level and will be sucked into the kernel.
They move Frontier lists and tables in two directions, converting from XML structures to Frontier lists and tables; and the other way, turning a Frontier list or table into the equivalent tagged text.
Things you can delete
These pieces are no longer needed:
All this is laying a foundation for a new namespace that Brent and others will build that will connect Frontier's object database to the new RPC mechanism, for Java and other environments, and all kinds of things we have just begun to think about.
Let's have fun!
PS: Discuss on the Frontier-XML list.