It's time someone solved the problem of the Amazing Fragmenting Address Book. Unless, of course, someone already has and I just don't know about it. Which is certainly possible.

This morning, an acquaintance sent me an email informing me of her new email address. I use gMail, so I was able quickly to update her record in my Contacts list in that program. As I edited her record, I realized that gMail would also allow me to have a full address book with addresses, phones, etc., if I wanted to use it that way. I'm not sure what value that would have, given that all I use my Google Contacts for is email, but the realization triggered a cascade of queries.

I have my Address Book from Apple which was always my main repository for such information until I started using gMail and it was easier to store peoples' email addresses in my email program. (Yeah, I realize I could have stayed with Apple Mail and had cross-integration there, but Mail just isn't as good as gMail in a number of ways. Besides, I do like the idea of having my contact info in the Cloud.) The Apple Address Book is where I keep mailing addresses, company information, and miscellaneous notes about people.

Then I have Skype, which I use for at least 90% of my phone conversations. Guess where peoples' phone numbers are most likely to be current? Yep.

Finally (I think), I have IM contact identifiers in my Adium application, which is my current choice for a multi-protocol chat client. And I spend a lot of time on chat, from which I derive a great deal of value and convenience.

Now it would be interesting to contemplate a means for synchronizing all of those applications' data together, but my guess is that's a very messy and difficult task. But it does seem to me that it should be possible to solve the problem by:

1. Establishing a central repository of all contact info in the Cloud
2. Expecting these individual apps to obtain their contact info from that source when and as needed.

AIM, e.g., appears to store all of my AOL IM clients on a server so that when I open a new copy of the chat client on a computer I've never used before, the buddies list populates automatically. I assume other IM clients have similar features.

I think Skype does the same thing (though I'm less certain of that and haven't actually asked or investigated).

What I'd really like is the ability to have all my apps draw from a central repository just the data they need to populate their subsets of contact info (emails for gMail, IM handles for Adium, phone numbers and Skype user IDs for Skype, etc.). Then I just maintain that one database and all the others draw from it as needed. They could keep a local copy, of course, and check for updates at intervals.

Of the services I know about, Plaxo seems best positioned to do this, but their technology is strictly push; if someone I know updates their contact info through Plaxo, I get a notice. But there is no API for me to connect to even if I wanted to write a program to do this, which I don't necessarily want to do.

Pointers anyone? If you don't want to join my blog and post a response here, you can email me: dan at danshafer dot com.

There is an apparently widespread outage for gMail customers going on at the moment. It seems, from my perspective, to be cascading and growing larger.

Some people in Silicon Valley report their Google Mail down since last night. Mine worked fine until about 30 minutes ago when it started getting flaky. Now it's not working at all.

One of the risks of living in an interconnected world. I always find myself amused by people (sometimes, though decreasingly frequently myself) who start screaming at Google and throwing around words like "unacceptable" and "stupid" and "lame-ass". I wonder how many of them have servers with 100% uptime.

Email is as important to me as to almost anyone, I suspect, but nobody is dying here. They'll get it fixed. Relax.

Over the past few weeks, I've been investigating the new state of the art with respect to the Web as an application development platform, focused on Web applications rather than on desktop apps with Web connections. This is all part of my renewed interest in the "Zero-Pound Computer". If we can store our personal data in the Cloud and if we can run applications that run in the Cloud, we can (or so I claim) look to the day when we won't take computers with us when we move, we will simply move to a new computer and our software and data will follow us.

The five major online services who have opened their APIs to developers to encourage the creation of applications that run in the Cloud are Google, Amazon, Microsoft, eBay, and Yahoo. Together they are often referred to as the GAMeY players. A good friend and colleague, Laurence Rozier of Meshverse Journal fame, has been buzzing a bit lately about Amazon's interesting array of Web Services. Of course, I have been aware for some time of Google's offerings, being, as I am, a Googlite. I was aware, too, of Yahoo's efforts to create JavaScript UI technologies and scripting libraries and overall impressed with their efforts. These three (dare I suggest the acronym GAY or might something like GoogazonY be more appropriate?) are getting the bulk of developer attention, with Google leading the charge by a considerable margin and Amazon coming in a fairly distant third behind it and Yahoo.

But Amazon may have The Secret Weapon in all of this in its unique combination of SS3 (Simple Storage Service), EC2 (Elastic Compute Cloud) and AMI (Amazon Machine Images). Couple those with its less known DevPay service and you have a platform that can effectively become your company's server farm and micropayment management system. None of the other players have these tools, and that has some important implications for who can and will use these Web APIs.

I just purchased James Murty's Programming Amazon Web Services from O'Reilly and while I'm just starting to delve into it, I am already fairly impressed by the breadth of the Amazon offering, a breadth which doesn't come through in checklists of API comparisons like this one. (Don't get me wrong, though; that checklist is quite handy in its own way.)

Interesting side note. The example code in Murty's book is almost all in Ruby. Python samples are available via download, but it is surprising to me that Ruby got the front-row seat here. Without Rails, Ruby is a very interesting language but not nearly as mature as, e.g., Python. Strange choice by the author and O'Reilly. I'll have more to say about the Ruby Surge in another post some time soon. Unless I lose interest. :-)

I'm about to embark on a project that involves converting a large stack of handouts I've done in HTML over the years into a couple of books intended for publication both as eBooks and as dead-tree products. To do this, I need to convert these HTML files to PDFs that format properly, paginate well, look good from a type perspective, etc. In other words, I need a desktop publishing solution that plays nicely either with HTML or with some format to which I can easily convert HTML without headaches and lots of manual tweaking after the fact.

In my search, I ran into an Open Source DTP tool called Scribus that looks very promising. Some research suggests that it doesn't swallow HTML frogs particularly well (though it may not be too bad; I'm going ot run some tests later this weekend to see, I think). But Scribus imports Open Office format (.odt) documents and, as you may know if you've been hanging here for a while, I use OO to the exclusion of other office programs.

So I followed a couple of links and stumbled serendipitously into a marvelously useful and helpful blog maintained by Solveig Haugland, who has a rep as one of the premier Open Office trainers and writers on the planet. Wow. That blog has taught me about 15 new things in the first hour of exploring it.

If you're using OpenOffice (or its Mac clone NeoOffice, which I prefer and use daily), or if you're just thinking about switching from Micro$oft Offi$e to OO or NeoOffice, you really should take time to look over this wonderful work.

I'm off now to experiment with NeoOffice Writer to see if I can produce a book-quality PDF with it, directly or by importing from it into Scribus.

Oh, and Scribus has another nice feature: it's Python scriptable. Woohoo!