inessential.com: Frontier Dreams

Brent explains Frontier's beauty in a way only Brent can.

When I wrote about Frontier a couple of days ago, I was very careful not to "dream" about any features I'd like to see Frontier have. I started doing that, but in the end the post felt unfocused so I decided to stick to the questions rather than my ideas.

I'm pretty torn about the Python thing, to be honest. I worry that if you stored Python objects in the ODB, that UserTalk code wouldn't be able to effectively deal with them, and it would become a 2nd-class language. But then Python is pretty darn sweet, and maybe part of the bridge would be a way that UserTalk could introspect and deal with Python objects. Maybe. Python deals with Unicode, I can't remember if Frontier does.

If I had the time I'd go back into discuss.userland.com and find the many posts I made about Cocoa-izing Frontier, because Brent brought it up and it's intriguing. Back when I was advocating it, Cocoa was stil called Yellow Box and it (Rhapsody) was going to run on Intel and Windows as well as Macs. Oops!

Replacing MacBird with .nib files would be very very cool indeed. What about the reverse though, what about a Frontier runtime that you could embed into an app so that you could do the UI of an app with IB and the code for it in UserTalk. The app would start up the little mini-Frontier runtime and would have its own ODB and UserTalk environment to drive the application. The end user wouldn't even notice it... then again, since it was a Frontier app, you might consider letting your users poke under the hood, and give users the ability to add plug-ins and callbacks like how people do it in Frontier using guest databases.

I wonder, could Frontier's script editor be wired into Python's debugging APIs in such a way that Python code could be debugged someting like how UserTalk can be debugged in Frontier, with browsable call stacks and local variables etc?

As far as Frontier as a server goes, I think it'd take a massive amount of work to really bring it up to par with current server engines. It needs transactional database support, for one. That would be cool but I don't know if it's feasible. For example, each web request could have its own ODB transaction associated with it. The changes the request/response loop creates are only committed to the ODB if the request completes successfully (ie: without unexpected error occuring). Zope works like this and it's wonderful... if a request fails, it doesn't leave half-done changes in its database that you have to clean up. Plus, transactions can be un-done in Zope. I'll just dream about this for Frontier. It's beyond my ability to make that happen, which is an example of why I'm going back to school soon.

Also, the UI really needs to be separated from the back-end engine to be a good server, so that it doesn't have to run as an application on a logged in account. It needs to be able to run as a daemon on a headless server.

It's because I think getting Frontier to be a great server would be so much work that I think it makes sense to focus on its value in scripting and automation. And even if it did happen, I don't think it would really catch on, because it's not Java, it's not Perl/Python/PHP, it's not OO, and it doesn't run on Linux (yet).

See, now Brent got me started! I'll leave it at that, my lunch break is over. ;-)