Older blog entries for tnt (starting at number 32)

Open Source and Flash
I've been getting into the Flash world lately. Although Flash is basically a proprietry environment (that Macromedia did a good job of getting onto almost every browser in the world), there seems to be an open source tool set developing for it. ( If you build it, we will come :-) )

Typically, one develops Flash web applications, by using Macromedia's tool called "Flash". It is a GUI editor for building Flash Animations -- SWF files -- that lets you use drag & drop style developing, and lets you do programming through an ECMAScript based language called ActionScript. This might remind you a little of tools like VisualBasic and Delphi. Although, Macromedia's tool is designed more for artists, and is made to be "usable" and geared for them. It does this by using the conceptual model of -- making you think in terms of -- a timeline, clips, etc instead of windows, buttons, menus, etc. (Which is probably why so many artists I know just love this tool.) (I've never actually used it myself. But I've seen others use it.)

Although Macromedia's Flash software comes with a (commerical and proprietry) ActionScript (command line) compiler. There is now an open source ActionScript compiler called MTASC. One of the best things about it (besides the fact that it is open source software) is that it is much much faster than Macromedia's ActionScript compiler! (Just to get rid of any confusion I think some people might be having right now, reading this, these ActionScript compilers compile ActionScript code into SWF files. Not into native code. I.e., not into .exe's or elf files, or whatever the native code format on you system is.)

The open source Flash world seems to be "coming together" now, under the umbrella of OSFlash.org. The open source Flash community is "living" within its mailing list (and on the Wiki on the website). (If you're interested in the open source Flash world at all, go and join the OSFlash mailing list.) This site and mailing list actually was born of all the "off topic" posts on the MTASC mailing list. (There was clearly a need for OSFlash.)

Another interesting open source Flash tool is swfmill. The desription of it from its website says:

swfmill is a tool to process Shockwave Flash(TM) (SWF) files. It can convert SWF from and to an XML-dialect called "swfml", which is closely modeled after the SWF file format.

Apart from this xml2swf and swf2xml functionality, it also provides a libxslt-based XSL transformator that supports an extension ("swft") which helps with generating IDs for SWF objects and can import an SWF as XML using an XPath command (swft:document()).

The interesting part to me is that it lets you create Flash animations (SWF files) via an XML markup language.

To understand why swfmill is important, I should point out that, when making your Flash animation -- SWF file -- you can NOT accomplish and do everything in ActionScript (no matter how much you want to). There are some things that can only be accomplished via the Macromedia's Flash GUI tool.

This is probably somewhat frustrating to people coming at Flash from and Computer Science and software engineering background. (For me, my development tool of choice is nano. I can't stand IDE's and GUI tools. They just get in my way, and slow me down.)

Besides swfmill giving you another paradigm to do Flash development. swfmill also fills in the missing pieces of doing Flash development (using only open source tools) when using MTASC. (swfmill can basically be used to replace Macromedia GUI Flash tool. Although artists might not like this... since swfmill is NOT a GUI tool... but those who like to development they I do development will probably like it. It's like hand coding HTML.)

I'm working on developing (or encouraging others to develop) an open source RTMP server. Right now, I'm trying to understand the AMF data format (used in .sol files and for Flash remoting). It's been suggested that RTMP uses this format somehow. So learning this should help in reverse engineering the protocol. As of this writing, the AMF Specification is NOT done yet. But, if you want to see the work in progress document, it is at: AMF @ OSFlash. (Hopefully, I'll have enough free time to see this project through, and be able to produce an open source alternative to Macromedia's Flash Communications Server.)

New Netscape Browser
The new Netscape browser is out. I actually got a job offer to work on this, because of all my XUL experience and knowledge. (And probably also because the development was being done in Victoria, BC. And I live pretty close to that. In Surrey, BC.) It would have been a really interesting project to work on. Unfortunately, other responsibilities prevented me from being able to accept the offer. (Not to mention that, at this point in my life, I really don't like the idea of having to move to Victoria. It's too far from the Surrey area,... where all my friends and family are.)

We Need an Alternative to URLs
I've been thinking lately that we need an alternative to URLs.

URLs are great in that they let you "reference" or "point to" things. (Such as webpages, files, objects, people, procedures, e-mail boxes, etc etc.)

(Really URLs are the computer equivalent of a "name" in human language.)

However, I think URLs have some failings.

#1: It's integrated with domain names. "Why is that a problem", you might be asking. ("Domain names are alot easier to remember than IP addresses after all.") Well, first off domain names cost money. (Which isn't really the bad part.) The bad part is that people often don't keep on paying for domain names, and they loose them, and "great" websites, or webpages with little "gems" on them disappear. Things like Archive.org help. But, I think a better solution is needed. (Also, Archive.org doesn't get everything.) Perhaps if URLs, or a URL alternative, didn't use domain names or IP address then we wouldn't have websites and webpages disappearing. (Maybe if we used a "free" identifier that anyone could generate. Maybe something like a UUID. And have that mapped onto IP addresses, "hashes", or something else.)

#2: The protocols that a URL can use (as far as I know), technically, must be built on TCP. This makes for a problem. I'll give you an example.

I want to create a desktop application system that used UNIX/POSIX named sockets. And I wanted to "point to" the server for the application using a URL. How do I do that? How do I use named sockets in a URL? It's similar to a TCP port. However, I can't just stick in a "path" to a named socket where the port for the URL would go, since it would include slashes. I guess I could use some method of "escaping" the slashes. However, in using "named sockets" I'm no longer using TCP. And thus, it's not really a URL.)

Got a reply from James Andrewartha -- trs80 -- via e-mail, to my previous post , in regards to me wanting all browsers to have a open, standard, cross-browser, and cross-platform way to creating TCP connections.

James Andrewartha (trs80) replied:

xmlhttprequest is now the de facto standard for this sort of thing. Now with the buzzword name of AJAX http://www.adaptivepath.com/publications/essays/archives/000385.php it's a big feature of so-called "Web 2.0" applications. Also, if you read the recentlog, two entries below yours is a post talking about JSON which is a highly useful encapsulation to get data from the server to the client.

James Andrewartha (trs80), thanks for the reply. I am already aware of XmlHttpRequest, JSON, and AJAX. Been aware of them for a while now actually, even before the terms JSON and AJAX were coined.

There was a time when XmlHttpRequest was one of the best kept secrets of web development. I used to tell people, "alot of the the really cool stuff on the web is done with XmlHttpRequest". (When you make XUL applications, you typically make heavy use of XmlHttpRequest.)

However, I don't think XmlHttpRequest is good enough. Sure, it lets your webpage do things without having to "reload" the page. But that's only one of the problems we faced. (Not the only one.)

The problem with XmlHttpRequest is that it uses HTTP. And the problem with HTTP is that it uses the request-response paradigm. And this results in applications constantly having to poll the server. Which is bad. And it also has the client creating and tearing down TCP connections all the time. Which is also bad.

We need true asynchronous communication. And XmlHttpRequest only gives the illusion of asynchronous communication (because the webpage is not reloading).

I just can't get the performance I need from an XmlHttpRequest. (But I can get the perfomance I need from a TCP connection, using a custom protocol though.)

Complaints about MySQL Replication
It's great that MySQL supports replication. However, more needs to be done to make it work properly. (Or maybe I should say work "better".)

MySQL replication works by essentially sending SQL commands, from the master to the slaves, when the SQL command changes something in the master. Which seems like a good idea. And if nothing ever got screwed up and nothing ever went wrong, then this would be fine.

However, things do get screwed up and things do go wrong, so you need to write your software assuming this. Your software should either be able to detect when things screw up or go wrong, or check for it on a regular basis. And when your software finds out it did happen, your software should either try to fix it, or notifiy someone about it.

Here's some things that MySQL Replication should do:

#1 Check that all the tables have the same structure. (This should be pretty easy to do.)

#2 Check that the data in each table is the same. (At first this might seem like it would be difficult to do, in an efficient way, but it really isn't. You don't have to check every field in every row. If you were to keep a running "check sum" or "hash" for each table, then you could just compare those to detect a problem.)

"Why would any of these problems ever happen", you ask. Sometimes it's from human error. And sometimes if is for reasons beyond the MySQL database server's control. (Like a power failure, or hardware problems.) For example, people sometimes write to slaves when they shouldn't. Backups are sometimes out of sync. (So when you restore things from a backup, and you think everything is OK, it really isn't.) Hard drives have problems. Etc. I've even seen weird problems with replication synchronization that we just can't explain.

It's been a long time since I posted here. About 2 1/2 years. How time flys. (Still need to finish updating my profile though.)

I see that Advogato still does NOT allow people to post comments in your diary (or blog as they call it now). That's unfortunate. People typically post replies in their own diary. But, unless you are consistent about reading other's diaries, you won't see them. Even if you stick with the idea of replying in your own diary, there should be an automatic way of telling the author that there is a reply there. And an automatic way of telling people "blogging" that there is a reply there too.

For a little more than a year now, I've been the lead software engineer at BidClix. I really enjoy working there! Really nice and moral people. Family atmosphere. LAMP based. And, most of all, I like the people I work with.

I could tell you alot about how people really make money on the Internet. About just how big business online advertising is. I had no idea how much money was involved with those simple banner ads, tower ads, etc before I started working at BidClix.

OK, I'm going to start to rant now. I've been working on a project that has a simple goal of sending webcam images (and audio from a microphone) to a server via a persistent TCP connection. And I wanted to do this using common technologies found in most browsers.

I searched various technologies and found out that Flash has built in support for webcams and microphones. I thought, "great, flash might have everything I need". So I spent a day and learned ActionScript. And even found an open source ActionScript compiler called MTASC so I could do all my development on Linux. (BTW, did everyone else know that ActionScript 2.0 is JavaScript/EcmaScript. Because I didn't know that.)

Eventually I found out that using the webcam is tightly bound to the Flash Communications Servers. This server uses a protocol called RTMP -- Real Time Messaging Protocol. I searched to see if there was an open standard for this. There wasn't. I searched to see if anyone had reverse engineered it. No one has yet.

Thus, it doesn't seem like I can use Flash. The system cannot rely on closed protocols. And I have to be able to modify any server.

So what is RTMP really. IMO, it seems like a glorified TCP connection. Macromedia has a good business strategy with this (since browsers don't really let you create TCP connections). (Macromedia guards this business strategy by not letting you directly "get at" images from the webcam. Or else, you could export them to the webpage, and bypass the Flash Communications Server.)

Don't get me wrong. I'm not knocking Macromedia! I think they are smart for doing this. I suppose I'm knocking the browser makers. Well,... maybe I'm not really knocking the browser mackers, but I guess I'm imploring the browser makers to create an open, standard, cross-browser, and cross-platform JavaScript API for making TCP connections. If we really want Rich Internet Applications, then this is a must! Of course there are security issues to worry about. So, you should probably only be allowed to make TCP connections to the same host you came from. (Or, better yet, a host should have a mechanism where it can specify what hosts you can connect to.)

(BTW, if anyone is interested at all. The defacto mailing list for Flash coders is: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders. Just remember though, when posting, that most people on that list are NOT Computer Scientists or Software Engineers.)

Trying to get back into GStreamer. (Was quite knowledgeable about it at one time. I'm sure nobody there remembers me anymore though.) Started off by trying to install it. Tried following what was posted on the GStreamer Fedora Download page. Did a:

    yum install gstreamer-universe
and got a:
    Gathering header information file(s) from server(s)
    Server: Fedora Core 1 - i386 - Base
    Server: Dag RPM Repository for Fedora Core
    Server: Fedora Core 1 - i386 - GStreamer
    Server: Fedora Core 1 - i386 - GStreamer dependencies
    Server: Fedora Core 1 - i386 - Released Updates
    Finding updated packages
    Downloading needed headers
    Resolving dependencies
    .......Unable to satisfy dependencies
    Package gstreamer06-plugins-extra-dvd needs libdvdnav.so.0, this is not available.
    Package gstreamer-plugins-extra-dvd needs libdvdnav.so.0, this is not available.
    Package gstreamer-plugins-extra-video needs libfame-0.9.so.0, this is not available.
    Package gstreamer-plugins-extra-video needs libswfdec.so.0, this is not available.
    Package gstreamer-plugins-extra-video needs libswfdec.so.0(v0.1.4), this is not available.
    Package gstreamer06-plugins-extra-video needs libfame-0.9.so.0, this is not available.
    Package gstreamer06-plugins-extra-video needs libswfdec.so.0, this is not available.
    Package gstreamer06-plugins-extra-video needs libswfdec.so.0(v0.1.4), this is not available.

Really don't want to have to compile everything. Last time I did it, it was really time consuming, and had all sorts of dependecies. Hopefully someone on the GStreamer mailing list will be able to help.

Everyone seems to be creating avatars for themselves now. Well, if you are a South Park fan, then you can use South Park Studio to create yourself as a South Park character. Maybe Advogato can allow people to upload avatar images :-)

Well, posted my first article here: http://www.advogato.org/article/574.html. Curious to see what kind of response it will get.


Continued the work on VNC to add printing support. (The work continues.)

As part of my VNC work, I intend to create a library for VNC clients. It's purpose it to make the creation of VNC clients much easier. (Of course the library will handle the printing stuff too.) Which means that I should be able to use the same library to create the GNOME VNC Client, as the Windows VNC Client. (Of course, this is source code compatibility across platforms, and not binary compatibility.)

Well, I haven't written anything here for quite a while. I takes alot of work to start and run your own company... and work is something that I have been doing alot of. (But anyways, to the open source related stuff....)


Lately I've had the time to do some work on Moonlight|3D. First, I've adding alot to the website. The new web site is alot better than the previous one pager I had there. (I'll probably make it go live later today... or maybe tomorrow.)
I've also been hacking the Moonlight|3D source code. Right now, I'm doing some of the dirty work. Just going through the code, adding comments (to help other developers), cleaning up the code, fixing minor bugs, and doing some updates. In addition to helping out the other developers, this helps me understand the code base. (After I do this, I'll start adding some of the additions I'd like seen added to Moonlight|3D.)


I've also been working on VNC lately. I'm actually get paid, by one of my clients, for this one. I'm adding printing support to VNC. (This is the biggest thing I've had request, for VNC.)
Don't think I've mentioned this yet in my diary, but I'm now a member of the VanLUG steering committee. (I got asked to join after I started organizing the Linux Multimedia Conference.)
Also, to help better promote VanLUG, I've registered the domains VanLUG.com and VanLUG.org; and set them up on my web server to forward people to VanLUG.bc.ca. (These two domains, are the most likely mistakes, for the VanLUG's website's URL.)
Yesterday was the last day of COMDEX, here in BC, Canada. The VanLUG booth did very very well. And was one of the most popular booths there!
This year I volunteered and was there for the first half of the first day of COMDEX, and all of the third (and last) day of COMDEX, for the VanLUG booth. (So I was there for half of the conference.) I (and another person) set up some Multimedia demos. (The demos seemed pretty popular with the crowd). One on the demos displayed various Linux Multimedia desktop applications. The other demo was a DirectFB demo. (Both demos made it easy to talk about, and create a buzz about, the upcoming, and still unannounced, Linux Multimedia Conference.)
I did alot of talking while manning the booth, on a variety of topics... not all about Linux... but most were. Which is good! Linux got promoted. VanLUG got promoted. The upcoming Linux Multimedia Conference got promoted. And I was even able to promote my company. (As did the other volunteers there, who had a company or worked for a company, that dealt with Linux in some way.)
All in all, it was a great experience, and I look forward to helping out next year.
I find it amusing, what will come up when you search for your name on a search engine (like Google).
I did just that today, and found out that I'd been quoted in an article. The article can be found at: http://alumni.ucsd.edu/headline/wi02/022802_lindows.html
I've found that you can also find interesting results if you search for the e-mail addresses that you use. Or search for things that link to stuff like your homepage, your resume, or to websites/projects/etc that you have some affiliation to.


Just when I though I was starting to get some free time... to work on matterial, GStreamer, or Moonlight 3D... work picks up full speed.
And I just started writing gst-gen -- a mini-programming-language/compiler to generate GStreamer objects/plug-ins.... I hate having to put these things on hold!
What I'd love is to get some funding,... the way artist will get funding to work on pieces of art,... so that I could work on my various projects... and still be able to make a living, feed myself, etc.
GStreamer & Functional Programming
Well I actually had some free time today, so I started to create what I discussed in my previous Journal entry.
The tool I am creating is called: gst-gen. Eventually it will read a source file (of a yet to be created programming language) and then, from that, create header file and program source file (in C or C++) for the GStreamer plug-in. So far I am able to create the shells for the header file and the program source file. The next step is to define the new lanauge (which will probably be alot like haskell), and then write the parser, etc.


Played Roller Hockey. Hopefully the weather will be nice enough tomorrow so I can play again.
Linux Multimedia Conference -- BC Linux Conference
Work for the (yet to be announced) Linux Multimedia Conference moves forward.
It now has a website, although there is nothing really there yet. The website is at LinuxConference.org. I was amazed that that domain was available.
I've been talking to a professional artist about having him, and his company, design the look and artwork for the Linux Multimedia Coference's website, along with other types of artwork (... like posters, etc).
I've postponed the initial announcing of the Linux Multimedia Conference until we get something decent on the website. To me (and alot of people), a website is the face of you project (or business, or whatever). And, it would be nice if we have a decent face (i.e., website) for our conference.

GStreamer & Functional Programming

I've been thinking that creating GStreamer plug-ins using a functional programming language (like haskell, etc) would be powerful method to create these. (And get rid of all the overhead one has to deal with, from the GObject stuff, and other things). For example, we might have something like:
VideoEffect (x:xs, y:ys, i, k)   =

    ComposeVideo(   GiveAlpha(x, i),  GiveAlpha(y, 1-i)   )   :   VideoEffect(xs, ys, i+k, k);
Where this plug-in would do a simple fade transition. (Obviously this has some bugs... but I'm trying to make the code simple.)
I wish I had some free time, so I could implement this! But I don't... I have to do the work that feeds me.

23 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!