Doc trashed Oddpost for being MSI5/Win only and Doug Hacker pushes back and speaks for me. Pushing the envelope is great no matter what. Doc's feelings are irrelevant. In the past users, esp Mac users, have pushed this button to quickly. If a breakthrough happens and users flock to Oddpost, that's good. I see Mac users these days getting lots of stuff that Windows users don't have (I use Windows) and that's cool too.  [Scripting News]

I think I know where Doc is coming from. But I tend to agree with Dave. A few years back, I remember Dave posting about another web site that was trying to design pages with broadband in mind, so they were very graphic heavy, and had a lot of JavaScript for interaction. I remember thinking that it was very pretty and fun to play with, but I also felt like it was threatening my bandwidth.

You know when you get a new fast computer, and then companies start adding feature after feature to the software, so that the computer ends up feeling as slow as the one you replaced? That web page made me fear that the same thing was going to happen to my bandwidth. Web pages were going to bloat more and more, until my cable modem started feeling like a 28.8k connection again.

But it never happened, because the increase in broadband speed and adoption has not followed Moore's law.

I have since changed my mind. We DO have to keep pushing the edges. We have to keep having faith in Moore's law. We have to believe that we will continue moving forward, because the alternative is stagnation. I see that now.

In fact, some of the design decisions that I've been making for my current Python project have been based on what I think will get faster, rather than what is fast today. The code I've been writing to play with the Radio ODB from Python uses the following transformations:

ODB -> table.tableToXml() -> XML-RPC -> fTableXML -> python

and then back as:

python -> XML-RPC -> table.xmlToTable() -> ODB

The problem is that it is slow. It's been suggested that I toss XML-RPC and try to go direct, but I don't see that as gaining much. The XML-RPC overhead is not as big as you would expect. By far the most processing time is being spent in table.xmlToTable and table.tableToXml. I have a very good reason to keep using XML-RPC and the table verbs, and that is that UserLand is VERY committed to the utility of XML in general, and XML-RPC in particular, so I see those verbs as primed for kernelization, thus getting rid of most of my speed problem.

So, yeah, it's a faith thing, but I can see it happening.

Of course, another way to go about it is to add Python hooks to Radio, or expose the ODB entry points so I could write some C to couple Python to Radio. It should be somewhat simple to make Radio call Python.

1:37:31 PM    comments ()  trackback []