Jim's Great Questions

Forgive me if this is so obvious that it needn't be mentioned, but after reading the Scripting News page today, and reading about the possibility of including some current UCMDs in the frontier kernel, I realized "Oooh yeah... UCMDs are compiled for a particular platform and create a hassle in creating a cross platform root."

Then I corrected myself, because a win32 UCMD can be stored right there alongside the separate 68k and PPC native UCMDs -- Frontier has already crossed this bridge in a way with PPC native UCMDs...

But, then it hit me: UCMDs written in Java! Java means scripters could avoid having to call Frontier.whereDidIWantToGoToday or whatever you would call the verb that would otherwise be provided.

Of course, this has its problems too, like scripters and UCMD writers would probably rather not have to count on the JVM being around on that user's machine, as frontier enjoys a good amount of compatibility with rather old MacOS system's at the moment... Still, though, it seems that with the JVM being ubiquitous on systems coming down the pipes, there could still be some appeal for this.

Got a Java version of the UCMD kit in the works? =)

My answer

Right on about storing different kinds of UCMDs in the root. No problem there. Frontier 5 will have verbs that allow your scripts to know what the native OS is. Run the code extension that's appropriate for the current environment. Frontier will be the ideal cross-platform scripting and programming environment. You're right that the architecture is deep enough to carry more weight.

About code extensions on Windows, we're going to run DLLs from within Frontier. Bob Bierman is working on this. It will probably be part of the second public release of Frontier for Win32.

We wanted to get the code extension interface in early so other people could help us port the verb set. That's one of the reasons why Brent posted the page yesterday asking for info about UCMDs that have already been implemented. We're thinking now about how to migrate UCMD-implemented functionality to Windows.

By the way, the ODB Engine API will be available to DLL code extensions.

Your last question is intriguing. Right now we don't have anyone on staff working on a connection that would allow Frontier to host Java code. It would be great if such code could have access to the object database, and call back to any script running in the odb as with the DLL interface. I'm interested in investing in this direction if people have ideas, or working with Java people to get it working. I think there's a lot of power here for people working in Java.

Dave Winer
dwiner@well.com