Tags: mivascript


Are you listening, Yahoo!?

Ever since a good friend of mine registered his domain name, signed up for hosting with SimpleNet and got me to do the web design - back in 1996 - I've been working with the endless joy that is MivaScript (née HTMLScript).

This XML-based server-side language has been the bane of my life for seven years. It's a perfectly functional language, which lets me create database-driven apps which work flawlessly on the web; problem is, it's just too damn verbose a language to make coding any fun.

My latest project, started last week, is to design and implement a database to catalogue a radio station's music collection. It has separate databases for titles, formats, genres, labels and users, and the database cross-links between 'em -storing a format's ID number in the title database instead of the text value, etc.

The aim is to finish this before the next committee meeting, so the music team can start plugging in data before the next broadcast starts. Currently most of the new music is sitting idle in the Heads of Music's flats instead of the studio, a habit I think they picked up from their slightly incompetent predecessor.

In return for design help I have full access to the aforementioned web space, so I have detailed knowledge of changes behind the scenes. A couple of years ago, SimpleNet sold off all their shared hosting customers to Yahoo! Website Services, and since then the service has hardly changed at all.

On one hand this is a good thing, as I think we continue to take advantage of the supposedly unlimited web space and bandwidth that SimpleNet originally guaranteed; however, Yahoo! hasn't added any other services to the package except for unlimited e-mail redirects, which is nice but pales in comparison to the PHP+MySQL support they offer new customers.

I wouldn't mind ditching MivaScript in favour of PHP, but sadly I currently don't have the means or time to learn PHP from scratch. I tried applying to a hostmom and fellow LJ user (two friend hops away) for hosting, but I was rejected, probably because I put too much effort into the application.

I could configure my local copy of Apache (bundled with OS X, isn't it sweet?) to handle it, but that takes work. I did it once, but lost all the settings when I updated OS X. Hell, even if Miva Corp ported Miva Mia, their consumer-oriented personal pre-processor, to OS X, I'd be much happier than I am uploading my scripts each time I change them.

Regardless, it looks as if I'm in for an all-nighter, debugging and fine-tuning this thing. Wish me luck.

(no subject)

It's fun what you can do with MivaScript, despite a lack of all-important case statements. Multiple IF-ELSE statements can become tiring.

In the course of my current little project (which is still taking ages because of the number of pages, decisions and triggers involved) I've learnt how to manipulate the HTTP Request Headers to offer the required cookies when the script requests a remote document, and also how to detect Set-Cookie statements in the HTTP headers of a requested page and pass those cookies onto the end user, so it can then retrieve those cookies and pass them back to the remote site when needed, like a middle man.

All this so I can choose a couple of crummy tracks to play on a radio station, only because its web site includes so much unnecessary programming. Sad, too, because a lot of the underlying functionality's provided by nice, easy perl scripts. Sigh.


Quick note to say I've been ultra-busy over the past couple of days, doing something about not being able to access my favourite interactive radio station muzik.is. It involves a lot of coding in an obscure language, but saves me from having to ask a Windows-using friend to go there when I want to know what's currently playing.

I tell you, that site takes the award for biggest amount of unnecessary JavaScript used. Not to mention the Java applet, which even manages to crash Internet Exploder Mac on occasion. The site rejects Mozilla, any browser that doesn't support Java and/or any browser that doesn't support JavaScript.

What I'm actually doing is creating an interface: calling the actual relevant pages, then parsing them to use absolute <A HREF> tags etc. I might move onto more enhanced functionality later, but for now it's just look-only.

Still, it's a damn sight cleaner code than their own offering, and it even passes as valid HTML according to the 4.01 spec.

Back to work!