« March 2004 | Main | May 2004 »

April 20, 2004

So some of the too - rare footage of a certain child of mine has been made into quicktime video...all who care face Portland and say "Thanks Adrian!"

It's here, and here.

| Comments ()

April 19, 2004

So with new versions of Office, Mozilla, etc., coming out, we once again hear the call for everything to use the Mac OS X Address Book. Now, while I understand the desire to simplify data entry, and having multiple address books is a pain, the problem isn't that different applications have different ways of storing address and other information. It's that, thanks to Apple not opening up the iSync and other synchronization APIs, there's no way to easily and automatically share data between applications.

See, it's the sharing of data, not the sharing of implementation that's needed.

The idea of everyone using Address Book, or iCal as a data source is tempting. you'd only have to enter data once. You'd only have to deal with one implementation of the data backend. But, there are a number of reasons why everyone directly using Mac OS X's Address Book, or iCal, etc., wouldn't work:

1. Not all programs do things the same way. For example, Mozilla 1.7, Eudora, and Microsoft Entourage all allow multiple users per physical login. That is, within a given login, you can have multiple users each with their own mail and address data. Now, while the question of whether everyone needs these features is debateable, the fact that the users of these applications find this useful enough for these applications to have that feature is not. (In fact, this is a new addition to Mozilla, only starting with version 1.7) Now Contact allows for server contact databases that are shared among potentially hundreds of people. Address Book just isn't designed for this. You get one Address Book file per login, and everything uses that. There are allowances in the Address Book APIs for hiding fields within a record, so that applications that don't need to know what your GPS coordinates are don't see them. But there's no real way to create an entirely separate Address Book file within a single login. This isn't a crack against Address Book, but there are things it's not designed to do.


2. There's more than one good way to access the same data. If an application is designed around being able to manage thousands of entries, or having thousands of different users access the same data quickly and efficiently, then Address Book isn't going to work terribly well for this. Again, I'm not saying Address Book is a bad address book implementation, but just as you wouldn't want to dig a trench with a knife, you aren't going to get great results out of forcing Address Book to be something it isn't.


3. There's more than one way to use the same data. For example, while Mail, Address Book, iChat, and iCal have some basic integration, Entourage uses its own internal database to achieve far greater levels of integration and features than it could if it had to use Address Book. (For a more detailed explanation of why Entourage replacing it's internal address functionality with Address Book would be a bad idea, check out Dan Crevier's blog entry on the subject.) Now has its own integration needs and they involve some rather large networking requirements.

The problem with everyone using Address Book is that it forces them to design applications that only need what Address Book can offer. That's not a great way to encourage innovation. In fact, it's a fantastic way to stifle it.

However, there is one valid point to "All must use Address Book": We shouldn't have to manually enter the same thing multiple times, or manually use things like iSync.app to share data. This should just happen transparently, within user - specified parameters.

If Apple were to open up the iSync APIs, (Note: I'm using iSync here to represent the idea of OS - level, application - transparent, data synchronization. If I'm talking about iSync the application, I'll call it iSync.app), then we could have this kind of integration.

Right now, the only way to use the iSync frameworks is through iSync.app, which, while better than nothing, has some problems. It's a closed system, so there's no documented way to add third party plugins to iSync.app. It's a manual process for the most part, (you can have a one hour timed sync for some things, but that's rather limited.), so you have to remember to synchronize it. So if you only use certain applications, and certain devices, you're set. But if you want to synchronize your Pocket PC device to Eudora, you can't use iSync. Even if you do use supported devices, you still have to remember to synchronize them, and if you want to synchronize between multiple applications, it's a tedious process. There's no provisions for automatically detecting devices or applications that need to synchronize data. So if you don't remember to run iSync regularly, you can end up not having data where you think you do.

Which is silly, because there's no need for this.

If the iSync APIs were to be opened up, you could have all this data synchronized automagically, between any number of applications, and you wouldn't have to do anything other than telling the applications how to sync and what to sync. You could even have this running across a network, and you could do it in such a manner that it would just work.

For example; You create a new contact in Entourage v.Future. When you set up E'rage, you told it "Hey, automatically tell the synchronization daemon whenever I add a contact." So, you add the contact, and hit save. E'rage takes this data and packages it up in .vCard format, and packages that in a message that it sends to the Mac OS X internal synchronization daemon, (aka "syncd") "Hey! I've got new data to share, here, you deal with this." syncd takes it and says "Okay, this is vCard data, lemme see here, okay, I got me a list of everyone who's registered locally to accept new data, and hey, there's some network recipient too, okay, sending this vCard data out." The various recipients get the message and the data and they integrate it according to their settings, (or not). This happens in the background, automatically, so within milliseconds of you hitting save, all the other applications now have that data too. They can then use it in accordance with their own needs, in the way that works best for them.

You could do this with almost any kind of data too. After all, it's just bits. We push this stuff around in mass quantities every day. On a network, you could use Rendezvous to update nodes that come on the network. Basic support for this is already built into Rendezvous via the service discovery protocols. So a laptop coming back on the network could run two operations, data out, data in, and synchronize with other devices on the network automagically.

The advantages of this approach over the "one file to rule them all" approach are numerous.

1. The applications you use can retain their own unique advantages. I use Entourage because its feature set and implementation work best for me. If they didn't, I'd use something else. Really, the only thing I use Address Book for is iChat, and as an occasional backup for Entourage. The same holds true for iCal. There's a lot of people that use it, I'm just not one of them. But since iCal has a couple of unique features, such as the ability to email out reminders, I'd love a transparent way to integrate that with my Entourage calendar. Opening up the iSync APIs would do that.


2. It would allow for synchronization of things that Apple may never think of or want to put into iSync.app. Apple is chock - full of smart people, but they can't think of everything, nor should they try to. By making it easier to synchronize data between machines regardless of type, Apple can open up Mac OS X for all kinds of demented things. (No, really, think about this. If you can transparently synchronize data across machines on a network, then imaging machines gets a LOT simpler. You maintain a machine as an image station, and any changes you make to it are automatically pushed out to NetBoot/NetInstall servers. No more tedious editing of an image because you need to update a single plist file. Update the file, save it, BAM, iSync happens. The NetBoot/NetInstall servers could even update clients right then and there. You could integrate this approach with backups too. See, automation is cool!


3. It would make adding new machines or new applications that need the data that other applications already have a lot easier. Need to test a new email client? Well, it would be kind of nice if you just installed an iSync - aware application, and instead of having to run a lot of import/export routines, it just told syncd, "Hey! I need me some email settings data and some Address Book data here!" and a few seconds later, you were done. On a network, you get a new machine, and as part of the imaging, all this public Address Book and calendar data is automatically sync'd. Not from some static file that has to be updated, but from live, dynamic data that's always current. Heck, the entire web is moving to dynamic data, why shouldn't the rest of our applications do this?


4. You have better control over what gets synchronized and what doesn't. If you only want Address Book.app to take in data, but never delete, you could set that as a synchronization preference. The same for Now Up-To-Date, or any other application. If you didn't want certain applications to sync on the network, you could block that too. By focusing on sharing the data, and leaving the usage of that data up to the applications that need it, you gain a lot of capability, and you really don't lose anything.


5. If you use open standards wherever possible, (XML, vCard, iCal, etc.), then other platforms could integrate in with this. So if you have to set up a user with a Linux, or a Windows box, they could still take advantage of all of this, and vice versa. Sure, you have risks of infection, but you have that with any common format. PDF's can carry macro virii too.


6. If you adhere to open standards, you could implement security procedures for this. So you could tie this synchronization into various security schemes, such as Kerberos, SSL, etc. That way, only the people who shoud have access to your data actually have access.


7. You could have all the data sharing you want, and not have to give up any features or capabilities. Who wouldn't want that?

Please remember, iSync.app is only an implementation of iSync the concept, and not the best one possible. There's no way for Apple to ever build one Address Book, or calendar system, or synchronization application , or anything, that will do everything that every application needing that kind of data does. But they can allow applications to share this data transparently. That's part of what an OS is for, making it easier for users and ISVs to use that OS in the way that works best for them. This would open up Apple to a whole new set of uses that aren't going to happen unless some ISV decides to create their own open synchronization implementation.

This stuff could be so much better, but it's not going to be until Apple opens up the APIs. If they announce this at the WWDC, then it will be just as cool for me as any new iChat silliness could possibly be.

| Comments () | TrackBacks (2)

April 6, 2004

Well, thanks to the folks at MacCentral, and this story, we can see how once again, a product that costs less than ¹/₁₀th the price of Apple's top of the line, award winning video production tool, is pointing out that FCP is simply not that good unless there's a human in active control. Imagine Video, a new product from Yarra Valley Software, allows you to automate a good bit of QuickTime movie creation, like automatically applying a multiplier so that you can just batch increase the display size by two. Or decrease it. It's a pretty neat trick, and one that FCP can't do. But we should be used to that by now.

This has happened before of course, with such low - cost items like BTV Pro, QuickTime Player, and if you include DVD Studio Pro, iDVD, all of which, in varying degrees, allow you to automate repetitive tasks, or tedious tasks like setup, informational tag editing, etc.

Once again, just because you paid oodles of money for the number one NLE on the market, doesn't mean you have a production tool. This is a real shame, because you would think that for what you pay for FCP and associated hardware, that you would at least be able to automate monkey work. That is, after all, one of the primary reasons for computers. To free us from monkey work. Evidently that doesn't occur at the high end. Far better to have some human doing it. Keeps the economy going and all.

I could go, yet again, into great details why Apple needs to pull it's corporate head out WRT AppleScript, but i'm either preaching to the choir or the deaf. One is unnecessary, the other is pointless. But, if you get a chance, check out Imagine Video. They have some nice documentation of their AppleScript integration, and it looks really cool.

| Comments ()