Simple Cross-Network Scripting
I'm going to start telling the story about how XML and Betty will connect up to new client features in Frontier 5.0.2. Wish me luck!First, the goals
Our goal is to raise the level of net scripting in the Frontier environment.
- It should be as easy to call a script residing on another machine as it is to call a script in your own database.
- It should be easy to call code written in Java, running on a Java Virtual Machine, to move information into and out of the Frontier object database; again, across the network or on a single machine.
- It should be easy to connect thru other networking protocols such as DCOM and CORBA, with little or no change to the structure of a script call.
An example
Here's a call to a script that lives on our Betty server:
betty = "betty.userland.com:80" [betty].guestbook.add (user.prefs.mailAddress, user.prefs.homePage, "Hello!")Lifting the hood
Here's what happens when that code executes.
- In the Frontier kernel, the call is converted to XML, then an HTTP POST request is made to the Frontier web server running on betty.userland.com.
- On the server, thru the Betty responder interface, a script is called in a special table. Only scripts in this table can be called thru this interface.
- The returned value of the script is encoded in XML on the server, then passed back as the result of the HTTP call.
- Before the client script regains control, the value is converted into a native Frontier data type.
Few limits
Important point, all the user code in this flow uses fully functional parameter lists. There are no parameter tables. The handlers are simpler than Frontier website framework filters and the calls are identical, in every way, to calls that are processed locally.
There will be some limits on the types that can be transported this way. We do not have an encoding designed for outlines, menubars, scripts, or object database addresses. We will err on the side of not supporting object types that we don't know how to XML-encode. But many types, including tables and lists will be supported parameter and returned result types.
The XML is hidden
So XML is central to the implementation, but is hidden from the script writer.
That gives us the freedom to change the protocol without breaking scripts.
This is important because there is sure to be a standards process around this mechanism, and we have to be prepared for change and we want to move forward independently of the standards bodies.This is possible because we're reasonably sure of the top-level functionality.
We will publish the spec for the XML we use. We want to work with others in the software industry on this, and at the same time stay focused on our goal to provide a simple and powerful interface for Frontier users.
An aside
We did this once before with good results.
Before Mac System 7 shipped, we released the UserLand IAC Toolkit. It implemented the equivalent of Apple Events on System 6.
When Apple shipped their software, it was easy to slip in new code behind the interfaces we had already developed.
So in other words, it's possible to develop for a standard even when there is no standard.
Our role in the standards process
We're a small company with a large code and user base.
As president of the company I think our energy is best focused on improving our software and learning how to build networked workflow systems with this new capability.
We have a very pragmatic use for this capability, it facilitates the development of more powerful content management systems, which is at the core of our strategy.
Compatibility with other networking protocols is the big win. We hope the energy for this idea builds and that the industry moves quickly to gain a consensus for a syntax and data structures and that people start deploying clients and servers quickly.
Even so, we immediately get compatibility with Java code, and of course can build powerful networks with Frontier running on all nodes. A lot of doors open, and there's a possibility of a lot more opening beyond that. It's a very exciting place to be.
We may play a role in guiding a standard, it depends on how the process goes, how the large industry players proceed and how the press covers it.
The top line
We want people developing in Frontier to be the most powerful developers on the Internet.
Dave Winer
April 2, 1998
|
This page was last built on 4/5/98; 2:22:09 PM by Dave Winer. dave@scripting.com |