Kyle Mulka's Blog

I think VoiceXML will be the next really big revolution on “the web”. Of course, its no longer the web because they aren’t really webpages. They are XML files that are read to you and have programmed responses. VoiceXML is an easy way for developers to create interactive voice response systems. Combined with a dynamic scripting language like PHP, these XML files can be very powerful.

Instead of a web browser, people will have voice browsers. These voice browsers will parse the XML, turn the text into voice, and receive specific voice commands based on what’s in the XML. Once a voice command has been interpreted, it sends it back to the server to fetch another VoiceXML page.

Notice how this way of doing things limits the bandwidth across the network and also makes the server extremely scalable because the server doesn’t have to do any processing of voice. Instead of sending voice across the network, we send text which the browser translates to and from speech.

UPDATE:

In response to Dave’s first comment below:

I’m pretty sure the blind already have this kind of technology to read web pages. In fact, I just looked it up and found this:
http://www.nfb.org/tech/webacc.htm

Sorry that I didn’t mention mobile applications in my initial post. I definitely don’t see voice browsers replacing web browsers on full sized screens. People can read much faster than they can listen or speak.

Depending on how small your screen is on a mobile device, it might be more efficient to listen than to try to read the screen. It is definitely faster to speak than to try to type on a very small keyboard if your device even has a keyboard at all. So, this would be perfect for small devices where the other methods of getting information in and out are inefficient.

Also, like you mention, it would be good while you are driving, because you need to keep your eyes on the road and your hands on the wheel. Or, you could just turn on the auto-pilot. Oh wait, we don’t have that for cars yet.

One of my professors from last year and a bunch of my friends have been developing Zattoo, a peer-to-peer video streaming technology back in Ann Arbor, Michigan. The client runs on both Windows and Mac and supposedly allows millions of viewers to watch a single live video stream over the Internet without costing the broadcaster a whole lot of bandwidth.

It is a little like BitTorrent in the fact that its peer-to-peer and doesn’t require the original person with the content to have a huge pipe to the Internet. It is very different from BitTorrent in the fact that the content is streaming. Timing makes a difference. If a piece of the video gets lost over the network, there is no need to resend it because you can’t rewind the video. There is no way to save the video to your computer either.

Just a few days ago, the news went out about Zattoo being the the system used for streaming the 2006 FIFA World Cup. That is very exciting news. I’m looking forward to being able to watch soccer over the Zattoo client in June! That is… if they are broadcasting to the US…

Quick-start, Long-play Internet Television Arrives with Zattoo P2P IPTV

Zattoo brings long play P2P broadcasting to Internet TV

UPDATE: Looks like Zattoo has a blog now! Yey!

Cosign is the authentication mechanism that the University of Michigan uses to authenticate users to their web applications. It allows the user of a web application the ability to use their standard University of Michigan uniqname and password with that application safely. The password is always transmitted directly to a secure central server (https://weblogin.umich.edu/) and behind the scenes, that central server tells the web application what the uniqname of the user is via a server side variable. This means that the web application never actually puts its hands on a users password, and even if the service is hacked, it will only affect that one service and not entire users accounts.

For this article, I’m only going to describe the University of Michigan’s implementation of Cosign. It is possible for other institutions to download the entire source code for Cosign and host their own central server which handles all authentication, but I’m not going to cover that since I don’t know much about the Cosign authentication server, just the Cosign which runs on the web server serving the specific web application you want secured via Cosign.

Examples:

• Webmail
• Wolverine Access
• UMOD
• CTools
• liveUgli (my current project)

In order to use Cosign, you have to have it installed on the server your web application is running on. Installing the Cosign client is no easy task. There are many things that make this challenging for someone who doesn’t really know what they are doing. Here’s some things you need to know in order to truly understand what’s going on here.

Cosign requires you have an SSL secured web page (HTTPS) for at least the authentication step of your web application. They reccommend you SSL secure anything that is not public that you have to be logged in to view otherwise user session to your web application could be hijacked.

In order for your web application to communicate with the central authentication server, the webmasters need to sign an SSL certificate for your server. This ensures that the communication between your web application and the central server is always secure.

Installing Cosign from source can always be an interesting challenge, especially if it doesn’t work the first time. I’ll try to go into this in more detail in another article. In the meantime, just check out these notes on my Cosign installation I wrote up a while ago, and the official Cosign web page.

It’s time to announce it to the world! I’ll be working for Amazon this summer in Seattle for about 12 weeks as a Software Development Engineer Intern starting May 8th. I’m really pumped!

Looks like Google is hiring in Ann Arbor… That’s cool. Maybe I won’t have to move after all. Unfortunately, I’m not a fan of server installation, so hopefully they will move into town with more software engineering type jobs. A few newspapers and blogs predict a Googleplex coming to Ann Arbor here, and here, and here. We’ll just have to wait and see.

UPDATE:
After a Google search, I found some more information about this. Looks like its official. Google is leasing office space in Ann Arbor, oddly close to where I worked last summer. What’s even more interesting in general is the fact that the company that vacated the space was also digitizing print media.

So, after several weeks of waiting, Merit was finally able to upload the webcast of the Google Maps presentation I gave at the Merit Joint Technical Staff Meeting on October 11th, 2005.

Just as a warning, the video is 45 minutes long and my not be the most simulating thing you’ve ever seen before. It is basically, an introduction to the Google Maps API on a very high level. I didn’t go into any code. It lays out what you can and can’t do with the Google Maps API, ho

“The space, the social network, thinking tools and the network interface in the same field of view. The boundaries between what is interior and what is exterior intersecting tangibly in front of your eyes.”

If you have interest in continuous computing, location aware devices, social computing, or similar stuff check this out. At least start reading it. I just started, and it is amazing me. It has a lot of good ideas about where we can take the location sensing technology. The PDF is linked to on the left of the main page.

The Headmap Manifesto

I’m excited that we got funding next semester for a project called Blue Puddle thanks to GROCS. Here’s the vision:

“The Blue Puddle software takes advantage of the Internet’s distributed authorship capabilities to create maps that draw on users’ collective memory and subjective experience of a city. These maps foster the emergence of stories about the city that are richer than any single author could create. The virtual digital environment created by Blue Puddle will serve as a catalyst for engaging the real built environment.”

We have a team of four consisting of students from the schools of Art, Architecture, Information, and Engineering. This should be both interesting and exciting considering we are from a variety of backgounds and I am the only undergrad.

Some of the technologies we are considering using include PHP, MySQL, GIS, and the Google Maps API. Fortunately, I am pretty familiar with them and am excited to be able to use them.

Paul Graham rocks! If you are at all interested in software startups, check this out. It’s dated 2001, and I think still applies for the most part.

The Other Road Ahead

Here’s a little story about PHP and Java… my two favorite languages…

Andreessen: PHP succeeding where Java isn’t | CNET News.com