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.

What's New

Since I haven't been able to blog for a while, I guess I'll throw an update out on what's going on right now.

I'm in the process of moving to San Diego, CA for work. I fell in love with the area after spending two weeks there earlier in the summer.

When I'm not working, I'm coding on my ArchShadow decompiler. Nearly 3 years after its inception, it's starting to take form. It is in its (hopefully) final incarnation, as an IDAPython script. It's finally getting to the point that it can handle complex code. The following are my test cases for ArchShadow:
Finishing reverse-engineering MSDRM (non-Janus)
Reverse-engineering the unknown parts of the Skype protocol
Some random cases (SC Info for iTunes in particular)

ArchShadow is my first piece of commercial software in a long while, and I can only hope it goes well. I'd love to at least see something come out of all the time I've spent on it haha.

Well, if anyone is in the San Diego (specifically La Jolla) area and wants to hang out, let me know... looking for people to talk geek with out there ;)

Later.
Lord Daeken M. BlackBlade
(Cody Brocious)

New Blog

So, I finally have a blog again. You may have noticed that daeken.com has been down for some time due to a server crash. Well, the server itself was up again within a day or two, but I simply haven't gotten off my ass to put the blog back up. I decided to simply move to Blogger to save myself a lot of time. I'm going to look into moving my old blog postings over, but I doubt I'm going to put the effort forth to do so.

If someone has a cache of the Project Statement for PyMusique, I'd appreciate it if you'd post it here or email it to me.

Thanks.
Lord Daeken M. BlackBlade
(Cody Brocious)