Re: Not key themes anymore

[Jim Pick <jim jimpick com>]

Russell Nelson <nelson@crynwr.com> writes:

> Someone suggested that the way to expose this functionality is through 
> a user-interface description language, which they pointed out is what
> XML is, in many ways.  This is a GREAT idea.

It's ok, it's nothing new though.

The nice thing is that Microsoft has decided XML is the future, it
mixes nice with ActiveX, so they are putting a lot of work into using
it, standardizing it, and most importantly - marketing it.  XML is a
nice open standard - so if Microsoft convinces everybody to use it,
that's not bad for us.

Here's how I see things stack up:

Here's a conventional web browser like Netscape:

 HTML -> Web Browser + Executable stuff (ActiveX/Java/JavaScript) -> User

For the XML approach to work to generate programs, you need the XML
browser to render the dialogs/windows.  So you have:

 XML  -> XML Browser + Executable stuff (CORBA, etc.) -> User

Microsoft is going to use IE to do this.  I don't follow them closely,
but I think they were talking about using IE/XML to do all their
dialogs.  I don't know if they will do this though -- usually
Microsoft screws things up and makes things slow, even though it
doesn't have to be.

This isn't really all that different from a conventional approach, ie.
using an interpreter or compiler:

 Scheme Source -> Guile Interpreter + Libraries -> User
 C Source -> C Compiler & Linker + Libraries -> User

The only real difference is that you call the HTML or XML a
"document", whereas you call Scheme or C "source code".  That's all
just semantics, really.  If you called Scheme source a "Scheme Markup
Language document", and Guile a "Scheme Browser" - it doesn't look
any different than the XML or HTML approach.

This does raise security issues.  If you implement an XML browser that
has code-executing qualities, you either want to limit it to local
files, or implement a security scheme like ActiveX, Java or Penguin.

A lot of people ragged on ActiveX, but it's not a bad concept (just a
bad implementation) - it would probably be quite decent on top of a
Unix kernel with better versioning and if it was less easy to accept
code from just anywhere.  Imagine a tag like:

 <object id="IOR:0112321..." src="http://www.gnome.org/rpms/myobject.rpm">

(or something like that - I'm not sure what the exact W3C <object> tag
 syntax is supposed to be like)

You'd only accept signed code from gnome.org, debian.org, redhat.com,
etc.  This might be configured by the sysadmin.  Possible even CORBA
callbacks could be used to filter on regexp's, etc.  Dynamically
loaded packages could be installed into user space.  Cacheing and
mirroring mechanisms would be used.  This isn't any different than
manually downloading Gnome .rpm's or .deb's and installing them - it's
just more automated, so you have to be careful.

Cheers,

 - Jim

PGP signature