January 2004

Galago – Finally some progress!

After four days of hacking, Galago now provides enough structure for a program to act as a feed for presence information, and for others to request that information. This includes information on a user’s service, the status(es), away message, etc.

There’s currently only one method for requesting presence. It blocks until it receives a response, but there will be two more methods. The first new method for receiving presence information will be a function that takes a callback function as a parameter. The program can continue going on its merry way, and the callback will be called with the new presence information when it’s finally available.

The second new method will be to use a GalagoWatch. GalagoWatch will be used for both presence and associative information, but for now, I’ll concentrate on the presence. You initialize a GalagoWatch, feed it the information needed so it can do its queries, set a callback function, and then start it. Any time the user’s presence information changes, the callback will be called with the new information. This would be useful for widgets and such.

It’s exciting to see it come together. Once I implement those and clean up the server a bit, I’ll be writing a Gaim plugin that acts as a feed, and a widget to display status information for the user passed to the widget. Exciting 🙂

Best Bugs

I was having a chat with my brother earlier about software bugs, and I started trying to remember about the best bugs I’ve encountered in software I’ve had a hand in. Below are my list of favorite bugs that I found entertaining. I’m kind of curious as to what other people would choose for their favorites.

My favorite bug would have to be Gaim’s flying buddies. When the rewrite of the Gaim buddy list was commited, in 0.60, we had a fun little bug where the drag-and-drops weren’t completed. This triggered a Gtk bug (I think it was Gtk’s bug?) where the nodes in the GtkTreeView would fly around the screen a bit from point A (where the node originally was) to point B (where the node is now). When the buddy list was off-screen, this made it particularly fun. As these were flying around, we quickly named them Flying Buddies.

Between classes one semester, I wrote a Snake game for my TI-89 calculator. It was rather easy to do, but I had an off-by-one error that generated what I called “snake droppings.” When the snake ate one of the blocks on the screen, it would of course extend. As soon as the tail started moving again, it would leave a pixel or two behind, hence the name.

My third favorite bug was during the development of my BilliardZ game for the Sharp Zaurus SL-5×00 PDA. Occasionally when hitting a ball, a big black hole would open up on the board, and the ball would disappear in it. Playing pool with black holes littering the table is a little inconvenient. I’m still not sure what caused it, but I ended up fixing it.

Speaking of bugs, something messed up on gnome-blog. I’ve spent over an hour trying to get it working again. Works now though.

(Update: I somehow lost the top paragraph. I don’t know how, but it’s back. That should provide more context.)

Galago Presence, Gaim Status

So far, the Galago framework is coming together rather well. I don’t have anything that runs and communicates yet, but a lot of the base framework has come together, and I expect to build test programs by next week (assuming all the other busy things in my life don’t take up too much time).

At the moment, I’m working on the Galago Presence stuff. I’m running into design problems that I also have with Gaim’s status rewrite. This is to be expected, since the two are essentially the same thing.

The main issue I had in the Gaim status rewrite is that I wanted to generalize status types, and provide a mechanism for multiple types to be set at once. This also requires that some times exclude other types from being defined. Unfortunately, this creates a big mess when registering status types.

My vision for Gaim status is to cover all aspects of a user’s status. Their online state, offline, away, brb, idle, whether they have encryption enabled, mobile communications, etc. The display in Gaim would be the same as it is now, with the exception that the Away menu would be a little different, as would the away dialog. Icons would still appear in the list.

The problem comes when we want to say, “away implies online” or “online excludes offline” or “I’m online, away, but hidden.” It can get confusing, so it needs to be done in a simple fashion.

Now, back to Galago and status. How detailed should status information be? We probably don’t need to know every little detail like we do in Gaim, but maybe we do? How do we standardize it then? It’s easier when we have control over the source tree in Gaim and can make status IDs all match, but when we have third party applications defining their own IDs, it doesn’t work so well.

The approach I’ve taken in the Galago presence code currently is to separate it out into a status type (an enum defining OFFLINE, AVAILABLE, AWAY, EXTENDED_AWAY, and HIDDEN, currently), a status name (“BRB,” “On The Phone,” “Away,” “Online,” etc.), and an optional message (such as an away message). I believe this is sufficient for most purposes. It won’t allow the applications using Galago to display a mobile or game indicator or other such things, but it will give the generic status to those applications.

Another option is to do what we have above, but allow a person to have multiple statuses. That way, they can indicate they are away and are using a mobile device. This should be broadcasted as one presence packet, as presences for a single person on one protocol are not additive. The last one sent is the one that gets seen.

There’s still an issue with applications sending odd statuses, like the user is away and available at the same time, or they’re offline and online. I guess that’s up to the individual programs to fix. We can’t do all their work for them.

It’s still not as flexible as what Gaim’s status model will end up being, I’m sure, but it works sufficiently for most cases, in my opinion. If the user wants any further information on the user’s status, they can check their buddy list or whatever else is providing the detail.

With that in mind, I’ll probably move forward in that direction.

The Future of the Linux Desktop?, Part I

It seems there are a lot of interesting things being developed lately. I’ve been reading about GNOME Storage, which is a really cool concept. I haven’t played with it yet, or looked into the code, but I think that if done right, it can really add to the desktop experience. Perhaps it could be used as a feed for Galago.

Linux as a desktop system has, in my opinion, a lot of potential. Though I wouldn’t recommend it at this point to most people I know, I do hope for a day when I can. The reason why it has so much potential is that anybody can modify the source of any program to provide the integration, assuming there’s not an API and plugin architecture that would do the job. Of course, we all know this, but think about it. Work like Dashboard or Gnome Storage just wouldn’t be all that doable under a closed environment without a lot of collaboration and licensing between Microsoft and any other companies. Unless of course there’s an API available there, but MS APIs only go so far.

There’s a lot that can still be done. My goal with Galago is to be able to automagically retrieve information related to the task at hand on almost any supporting program, in a desktop-neutral fashion, and to have an indicator of a person’s status wherever you see his/her name, e-mail address, or other contact information. But this is just one small part.

I want to see a desktop where when I open my report for school, I can instantly see on the side of my screen or somewhere icons for the other files related to this report, URLs I accessed to find the information, and the status of any people on my buddy list I worked on the report with. I’d prefer not to see this in a big white window on the side, like Dashboard does and Galago will do, but something more integrated into the environment. How, I’m not sure yet.

Something else that may be neat to see in the future is a revision control feature built somewhere in the backend. I believe Gnome Storage has this in their plans, and I hope it ends up being a part of the desktop experience. I’ve had clients and family members complain that they accidentally deleted or overwrote a file they were working on, and wanted me to recover it. If this was built right into the system, their documents would be safe.

Drag-and-drop install/uninstall of applications is another feature I’d love to see. This was something that Mike Hearn brought up the other day. If a person could download a single package and drag it to their desktop to install, and then drag it back to the trash to uninstall, it would simplify package management for the user dramatically. Of course, this requires that we finally get packaging sorted out and standardized, but this isn’t likely to happen any time soon. However, his autopackage project does provide an interesting form of package management that I wouldn’t mind seeing take off. The rest could be abstracted through GNUpdate.

At this point, I’d like to bring up how cool the stuff Robert Love is working on. It’s one of the upcoming things that are really exciting me.

I had more I was going to bring up, but it slipped my mind, so I think I’ll end this post….. now.

Galago Notes

Just before I go to bed, I figure I’ll jot down some notes regarding Galago, as I’m sure I’ll forget a couple of them in the morning.

The storage of the data is going to be in a graph. I think this is fairly obvious. Using this, we can better fine-tune how specific one thing is to another.

We should allow the user of the API to search in many ways. Keyword searching, mime-types, and categories are a few that should not be left out. We should also allow data to be retrieved within a span of time.

Speaking of time, items should be set so that they have an expiration date and one or more dependencies. The dependency (perhaps almost all information?) should be in the form of a URI. So, a feed may push data with no expiration date but a dependency on a file, along with any relevant data, to the galago server, and the information would be cached and accessible, even if the program had been closed for awhile. If that URI no longer existed (say it was a node in the graph, or a file on the harddrive), the entry would be purged.

And it’s late, so enough rambling. Bed.

Shiny New Battery Back-Up

For Christmas, my parents gave me a CyberPower Battery Back-Up system. It’s a 410 watt unit, claiming to last 25-50 minutes. I really only need 5-10, since these systems are only off when the power flickers or PG&E screws up somehow. So today I finally installed it, as my main desktop locked up. I figured it was now or never.

What can I say? It works. It’s fun to pull the plug out of the wall while the computer is running (I only did it once!)

This doesn’t even compare to my friend John’s setup. He needed something for one of the businesses he’s a computer consultant for. It had to last 2 hours, so what was his solution? Why, building his own out of 4 car batteries, of course! It generates a bit of heat, but it works, and has worked for some time. I want him to build me one, but then, I only need that 5-10 minutes.

Food For Geeks

I’ve been discussing a small site I plan to setup with some people. The site is called Food for Geeks, and is essentially a food donation system for Linux hackers. It works like other monetary donation systems, but instead of specifying an amount to send the person, you’re presented with their favorite foods. You don’t actually donate the food. Rather, you donate the money for a type of food, and it goes into the person’s PayPal account.

Really, it’s a wrapper for PayPal, but more geared toward rewarding food. I feel this would be more personal and fun, and gives the donator some idea as to what the person will be buying with the money.

The system itself will be easy to setup. I have the space and bandwidth, and developing the backend won’t be a problem. It’ll allow users to setup accounts with their portfolio, list of projects, and their favorite foods, along with the prices. They can then place a little button on their site, which other people may click. They’ll be presented with the food the donatee listed. Clicking a link will open up probably a PayPal Donation page with the price for the food and all the relevant information.

It might be crazy, but it’s not like it hurts to try. I just need some good graphics made, and I can do the rest. Failing that, I’ll do some mediocre graphics 😉

Galago

I’ve been developing a draft of a system I call Galago, which will be used for associative information gathering (based on ideas from Nat Friedman’s Dashboard) and user presence information. I discussed this briefly on Advogato.

This is not all fledged out yet, but the current concept uses D-BUS and XML packets for communication. Every Galago Feed, which may be an application (such as Gaim) or a daemon, can push information it finds to the Galago daemon and/or listen for requests for associated information. Other applications (or even the same ones) can make these requests and retrieve the results.

The trick is deciding how I want to format the requests, figure out what information to return, etc. I’m thinking that a combination of categories and mime-types would work, but I don’t know how easily that will scale to things I haven’t yet thought of. It would require a standard repository for categories.. Must think about this more.

Another area of Galago would be presence information. Any application that can provide presence on either the home user or remote people would push it to the server or wait for a request and respond. The basic idea is simple. Any time you see a person’s name or information, whether it be in Evolution, Gaim, Straw, Pan, or whatever, you’d be able to retrieve information as to whether they’re online, what services, and their status (away, busy, etc.). It doesn’t matter what IM client you use, as long as they support Galago.

The base of Galago is composed of three parts: Galago Core (the main communication protocol), Galago Presence (presence and user information), and Galago Association (related information gathering, a la Dashboard).

I should mention at this point that Galago wouldn’t be designed as just as GNOME thing, even though that’s how it may appear from the examples I used. It would hopefully be more like a freedesktop.org standard, where it’s desktop-neutral. It would have libraries with controls for common assocation and presence indication, such as a little online indicator icon, a Today view control, etc. There would be Gtk and Qt versions of these.

I’m drafting up some ideas for this, and trying to figure out the protocol and get a base system up. It’s moving slow, but it’s moving. I’ll post more as I go.

Scroll to Top