Content Delivery

Every developer has, at one time or another, considered what the next methods for content delivery will be. In the early days, we had BBS's. With the coming of the internet, we had Gopher, then HTML. HTML was great when we needed simple text and static images, but we've moved on from there. We now desire interactive graphics and streaming content. VRML was one early way this was accomplished, but it never took off. I'll cover VRML later, but right now let's focus on HTML and other more common web technologies. These things we desire are where JavaScript, Flash, and a half-dozen other technologies come in. They work to fill the gaps HTML leaves. This isn't to say HTML doesn't serve its purpose, but we're pushing it to do things it's simply not meant to do.

We need a change. We need to stop beating the dead horse that is HTML. The problem is that we keep ending up with proprietary replacements that perform poorly and are designed even more poorly. Flash and XAML are two fantastic examples of this. They both share the same basic concept: applications should be simple to design, run in any setting you want them to, and do what you want them to do. Flash does this fairly well: its design tools are simple to use, it runs on many systems, and most of the time they Just Work (TM). However, its design tools are commercial and few (if any) good replacements exist, it is a primarily proprietary system in that it is not completely open for producing and rendering, and one organization controls (almost) every Flash player implementation. XAML suffers from many of these same issues, though it's unsure whether it's going to be available beyond Windows.

So what can we do? Well, for starters, we need to design a system that provides every bit of functionality current systems provide. This means everything from basic elements of web sites (2d text, forms, etc) to animated graphics and dynamic content. This is a big undertaking, but not impossible by any means. That is the first goal.

The second goal is simple: complete interoperability. HTML was great at this; you could browse an HTML-only website in the most 3d-rich environment or from a simple text-based console. Sure, you could make it easier to use, but HTML could never truly scale. You could never take advantage of the environment HTML was running in because of its simple design, and if you attempted to use Flash and the like, you ran a good chance at blocking out potential users. So what's the solution? Build in layers, separating content from display. You shouldn't have to build your site in 3 or more ways (Flash-only, HTML with frames, HTML with no frames, etc) just to make it usable to everyone, it should be part of the design.

Before I get to the next goal, I'd like to go back to VRML for a moment. VRML stands for Virtual Reality Markup Language, and it was just that. With VRML you could build complex (for the time) 3d worlds, and with extensions from companies like Blaxxun you could have multiple people cooperating in an online world. (Cybertown is a good example of this) The problem was that because of the limitations of systems (both clients and servers) and limitations of bandwidth, no one could truly take advantage of this technology. Later, X3D was designed by the Web3D Consortium to replace VRML, but it only took off in a very limited space. VRML and its kin are essentially dead in the water, despite being fantastic concepts.

The third goal is a bit more complex: unlimited 3d content that scales. If you're on a powerful system, you don't want to look at graphics from 1995, just like when you're on a portable concept you don't want to have such high quality graphics that you can't move. By designing the 3d system to allow for scaling content, and designing tools (and retrofitting existing tools) to do so, it's well within reach.

Now, everything I've said seems fairly straight-forward really. Non-trivial, but straight-forward. There are a few dilemmas I am faced with while thinking this through, the biggest of which is this: How will the actual logic be done? It's very simple to throw content at various devices and have them render it, but it's far more difficult to design the system in a way that you can do actual logic in it. Being a Python fanboy, it is my first choice, but this is really where something like .NET reigns supreme, because you're not tied down to one language. Parrot would be an obvious choice if it were more mature, but as it stands, it's not even an option.

So that said, I'm very interested to hear what everyone thinks, and maybe one day we can move forward with this.

Later.
Cody Brocious

Edit: Alex Goodwin commented about .NET not being a good idea to him, and I agree. I forgot to add that I think .NET is a poor implementation of a great concept, and that I have no intention of using it.