From MobileMe to Google Apps: A Progress Report

It is disappointing, the hassles facing MobileMe users, and I'm sure the team(s) within Apple are pulling their collective hair out trying to find resolution. And I'm sure Steve and the management team are not a little bit irked that this persists in the face of today's earnings report. There will be some shareholder angst to be sure.

On a smaller scale, back in my days as an IT Manager, I recall well the departmental shift into crisis mode when services went dark. But one thing was for certain, customer service became the critical priority externally, while service restoration becames the #1 internal priority. It seems that Apple is having a tough time with this.

As for my own MobileMe experiences, blogged about here and here, I decided to transition to Google for email and calendaring. Jury is out on whether or not I'll use Google's online office. The interface is yet quirky, although it is certainly functional.

If Apple were to put iWork online, that'd be pretty swell, if not an extremely daunting task (for Apple's engineers).

I pay daily visits to MobileMe with hopes things have improved only to find they haven't. I won't rehash all the reasons for me switching, suffice it to say, Gmail and Google Calendar (Gcal) are excellent apps, in particular the sharing functionality of Gcal. Picasa Web Albums is also excellent. It differs primarily from MMe's Photo Gallery in looks, which are pretty slick appearance-wise, I'll chalk that up to MMe's favor; however, looks are not everything.

From Mail/MobileMe to Gmail: Gmail wins me over for superior online options, customizations, tagging, calendaring integration. The usual suspects creep up with any address change: getting people to change to the new one. It hasn't been too bad thus far, but could be better.

Transition has been smooth, and the thought of losing our .Mac addresses is less troublesome with each passing day. I suppose you could say that the breakup is not as bad as I thought it'd be.

From iCal/MobileMe to Google Calendar: Couple things here. iCal/MobileMe is a local/online solution. Locally, iCal beats Gcal because it has ToDo's, and it is local. With Google Gears on the horizon for Gmail and Calendar, and the excellent plug-in architecture for ToDo's in Google services, it will be come local for 1-3 months in advance...

Still, for online Calendaring, MobileMe calendar is a long way from competing with Gcal. Sorry, but it just is. So Google Calendar wins here rather easily. The transition has been smooth since that is what actually started this whole thing back when MMe was announced.

Do I mind that it isn't local? Meh, maybe sometimes. I haven't yet had an outage during which I needed my calendar info. Yet.

From MobileMe Photo Gallery to Picasa Web Albums: Here again we have the interface being the main difference between these two. Google has gone to great strides integrating PWA into iPhoto; however, it is still a few extra steps and less elegant. Just like you're able to change the "Mail" icon in iPhoto, I'd like to have a PWA icon to upload to that service instead of Exporting to the service.

And the online experience goes in favor of MMe Photo Gallery simply because it looks better. But functionally they are on pretty much the same playing field. Where PWA pulls ahead is in sharing of albums - public or unlisted, and in ability to purchase from the web page. No option in MMe Photo Gallery.

Thus the photo situation has not been a difficult transition. But I will say that I liked .Mac's video viewing back in the day when I used it. That was cool. Haven't tested that in PWA, so don't know how/if it performs.

From AddressBook to Google Contacts: This one has not been as easy. Google Contacts seems like more of an afterthought than a great service/feature. It does most of what I need it to do, but for some reason the interface bothers me. It is not as clean and easy as AddressBook. And MMe's online AddressBook is quite nice, although again, there's more that you can do - online - on the Google side of the fence here.

From iDisk to Google (?): Um, no. There is no from iDisk to Google because Google falls down here. Yes there are hacks that allow you to use your Gmail space as storage space, but I don't like that solution at all. If Google were to offer an iDisk-like alternative, that'd be great. They don't, so it ain't.

This is the one area that is stckiest. Bottom line for me is that iDisk alone is not worth $99/yr. if I'm not using the rest of the service. For you it might be. I'd rather go to Costco and pick up the under $200 750GB Western Digital external drive. That's 2 years of iDisk with vastly more storage space. Granted, it isn't in the cloud, but it's more practical in this case. There are free online storage systems, I'm subscribed to Box.net which I like, but it has less space. Did I mention it is free?

Conclusion: The transition from MMe to Google has been going very well, the only areas that fall a bit short are with AddressBook and iDisk although there are solutions both free and shareware.

Any of you switching from MobileMe to Google?

MobleMe Continues to Disappoint

As I mentioned in my last post, I've been an iTools/.Mac/MobileMe user since it was a free service. It has taken me, I guess, 8 years to come to the conclusion that it no longer meets my needs, therefore, it no longer justifies $110/yr.

Some of you reading this will undoubtedly disagree finding MobileMe meets your needs and then some. That is great and I'm glad it works for you. For me the cost is a too high considering the free services out there. But I totally understand the ad-free MobileMe service, I really do. If it were free, of course I'd keep it, but I'd still be critiquing the offerings in light of my needs all the while gazing over at the Google side of the fence.

So I write this a bit surprised at myself. It is almost like an awakening from a strange RDF-induced dream I've been in for so long. Gosh it feels weird to write that.

The conclusion I've arrived at (as of today - gotta leave myself a way out in case the RDF returns) is that the service Apple provides is not really geared toward users like me any more. As I read over the weekend (can't recall where), MobileMe is geared for (best taken advantage of by) the iPhone generation more than the non-iPhone set.

Not that we non-iPhoners can't use it, don't get me wrong. But for me it boils down to functionality, customization, and flexibility. I want it to be more like Google Apps, which I suppose is why I'm moving that direction.

I've mostly loved Apple's no nonsense, K.I.S.S. approach to hardware and software as opposed to Microsoft/et al's "how much useless stuff can we fill this PC with" approach. And for so long I've lumped Google into that latter category - until now.

When people extol Google's Gmail, Calendar, etc., I used to yawn and turn away (except for Picasa - hurry on that OS X version guys). No more. It is really weird - having been a Mail user since the beginning, even bringing Gmail down via POP access - how much Gmail's online methodology has grown on me. It has become more intuitive, even addicting.

Over the weekend, and today, I put MobileMe thru the paces, you know, giving it a chance. And yeah, I did say Apple may work out kinks in the coming weeks so I'd give it more time (and I will as I've got 90 days left before renewal). But even as MobileMe has sped up a bit, I still find it *way* to slow. And I find the lack of customization leaving me indifferent to the service as a whole. MobileMe Calendar, IMHO, is a complete waste of time. Just doesn't work for me or my workflow.

IMHO, MobileMe is polished on the outside, but lacking in "meatiness" on the inside. As Clara Peller said, "Where's the beef?" This is one instance where I wish Apple put a lot more stuff into a product beside looks.

As mentioned in the first paragraph, I do not plan to renew our membership with MobileMe. My wife and I already use Google Calendar, and have all our .Mac/MobileMe mail filtering through our Gmail addresses. A long relationship, custom .Mac/me.com email addresses - all things I've loved about Apple's iTools and .Mac, seem to no longer hold sway over me. And it feels weirdly liberating.

iCal & MobileMe or Google Calendar?

Caveat: as for a lot of computing, preferences are entirely subjective. These are my opinions based on how I use iCal, Google Calendar. Your MO may be quite different from mine. That's okee-day. I happen to know there's a lot of folks pondering whether to keep paying the fee for MobileMe, or jump ship to free resources. Perhaps we can help each other out with some sage advice.
------
I've had great expectations for MobileMe since Jobs announced/demo'd it at WWDC. On the other hand, I was on the edge of diving into Google Apps more (Calendar) for family scheduling purposes since iCal was not filling the need adequately.

Needless to say, I was quite excited about MobileMe, thinking my $110/year (extra email) would now be more justifiable.

I'm one of those folks who has been with it since it was iTools. Every year a new iLife was announced with .Mac integration I got excited - but rarely ever use the additional features. Pretty much just email. So with the whole "push" thing, it seemed like it just might get there.

Since MobileMe was a ways out, I decided to give Google Calendar a whirl (not just toying with it as I've done for a year now). See, my family is down to two computers. My aging 17" PowerBook, and a "new", cheap P4 for family stuff. Though my work life is all about Apple, I'm one of those who just can't afford to lay out the $$ for a family iMac (not interested in mini's).

I've never been a "cloud computing" fan, always liked local desktop apps. Still do, but I'm getting used to the Google cloud now, and actually enjoying it.

See, the best thing about Google Calendar is that my wife and I, from each of our Google accounts, can edit and save all the calendars we share (we set them up that way). Can't do that in iCal. The other thing, prior to MobileMe, is that we can access our calendars from any computer anywhere. Can't do that in iCal, can in MobileMe.

So we've spent the better part of a month immersed in Google calendar for our boys' swimming events, family events, work schedules, and lots more. But in the back of my mind MobileMe lurked - would it work as well as Google Calendar? To be honest, I was assuming MobileMe would totally replace Google.

However, after lots of patience trying to get in to MobileMe, and finally doing so, I have been thus far disappointed.

First and foremost, it is slow. Mail in particular can be excruciating say just trying to click on "Sent" items. Now I understand the servers are still seeing high demand, so maybe it'll peter out in a week or two. But wow, is it slow. Even on my P4 with XP Pro SP2 - which is a lot snappier than my 1.33GHz G4 with 2GB RAM - MobileMe is slow.

I wrote a buddy who recently bought a new MacBook, and asked if it was fast on his machine and he said "nope".

I was honestly expecting it to be as snappy as in Apple's demo videos with good 'ol John at the helm.

Next up would be iCal vs. Google Calendar. iCal has To Do, Google Calendar does not. But Google Calender allows me to go into a calendar and choose not only to share it, but to set permissions as to what others can do (edit/delete, etc.). That has been awesome for my wife and me. Same calendars which both of us can edit from different Google accounts. Updates are instant on either account.

iCal/MobileMe cannot do that. At least with my current set up with my wife only having an email account. But with Google, we share the same calendars from different Google accounts ... for free.

So when I logged in for my wife. The only icons accessible to her were Mail, Contacts, and Account Settings. No calendar. I shook off the cobwebs and realized that's because she's email only. So I looked at Amazon and saw $135 for the MobileMe Family Pack, $150 at the Apple Store. Ugh, more money.

MobileMe = $135/year with no ads, a beautiful interface, we get to keep our beloved .mac/.me addresses, 20GB space - OR - Google Apps = FREE with ads (though to me they're unobtrusive), so/so interface with @gmail.com addresses, and less space. Hmmm.

Let's see, gas is $3.91/gal here in Hampton Roads, VA, our energy bills are set to jump over 9% this year, maybe more. FREE looks awfully attractive. But there's that nagging feeling that I'd be losing a friend - those (formerly) prestigious @mac.com addresses. See, I've been a member since iTools, so it is sentimental.

So I decided to see if I could duplicate what we can do in Google Calendar in iCal: share a calendar with ability of assigning another person (wife) to edit and share from another account. Nope.

I was also excited about the whole Push thing. But I don't do iPhone (I'm a Verizon guy), so that doesn't matter ... and I don't do any data plans or email ... so it would be pushing between the cloud and my computers only.

So here's where I'm at: Google's Calendar is FREE, fast, stable, can be shared editing-wise. It is not as glamorous as iCal, doesn't have To Do's. It does have Google Notifier which is pretty darn awesome up in my menu bar, thank you very much.

iCal, local and pushed to the cloud, elegant client locally and MobileMe-ified. $110/yr, currently much slower than Google Calendar, can't be shared/edited in the cloud between multiple users, only viewed via subscription.

As of now, the balance is leaning toward Google Calendar. I will, of course, give Apple a few weeks to sort things out, namely speed. I don't see them altering how iCal is shared at this point. But for Apple to tout this as Exchange for the rest of us, they need to make calendars editable by the likes of secretaries in small businesses, co-workers, and family members.

Firefox 3.0 RC2 - AppleScript still broken, Safari 3.1.1 to the rescue

I've got a confession to make. Safari 3.1.1 is a really good browser.

Mozilla is losing me over this AppleScript issue with Firefox 3.0. Sure I use FF3 from time to time, but not for MacSurfer work or general browsing any more, unless I'm on my XP box, that is.

In my previous post back in March, I placed Safari 3.0 at the bottom of my browser list and for good reason, 3.0 was not a good browser, unable to handle the beating I give a browser for MacSurfer work. But 3.1 changed everything. It doesn't choke, and with extensions like Saft, Safari Tabs and others (along with my AppleScripts), I can almost do everything Firefox did.

In fact, I've gotten so used to Safari 3.1.1 that Firefox seems somewhat foreign now - even a bit clunkier on the UI front, IMHO, while Safari is smooth and clean. Purely subjective, YMMV. And speed-wise, they're similar - both are, IMO, faster than Camino now as well as more compatible with plug-ins and general web suff.

Regarding AppleScript and FF3, I'd like to say thanks to Luis at WebnoteHappy for writing a post about Firefox - he references this blog and the entry I made in the Mozilla forums under "rdm44". Yeah, both are mine. He's obviously got connections so that's a great thing. I'm just glad someone with clout is taking the ball and running with it. Thanks, Luis!

I won't recap the script problems, you can find 'em here. Suffice it to say, RC2 fixes nothing, and since it's technically been out since 5/30 (at least that's the date that was on the FTP site and the file date) it is no surprise that Luis' patch hasn't been applied yet. I'm curious to know if his patch fixes ALL of the issues I mentioned...

Obviously Firefox does things that Safari can't do, namely the plug-in architecture, but for my uses Firefox can't do what Safari does and that's support AppleScript.

Folks who don't use AppleScript will find Firefox 3 a great browser. My issue shouldn't dissuade anyone from using it. Especially on Windows, FF3 rocks.Now, FWIW, I do have workarounds for Firefox 3 so I can use AppleScripts to gather titles and URLs; however, they involve GUI scripting and the use of the excellent Copy URL + extension. Not the prettiest workarounds, and because they make several GUI calls they're a little slower than usual.

If Mozilla gets around to fixing AppleScript support, I may use FF more frequently again, but I don't think Dave Hyatt and the Safari team will be idling around. I expect both FF and Safari to make continued strides towards excellence, so with that I'm optimistic.

Oh, if you're interested in helping Luis get the bug(s) fixed, he has a list of ways you can assist.

For those of you who use the MacSurfer submission AppleScript for Firefox, realize that it will not work with FF3.  You'll need to either stay with FF2, or switch over to Safari or Camino for submissions.  You can write me for submission scripts.

Firefox 3.0bX and AppleScript - What's gone wrong?

First off, I have to acknowledge that I should probably file a bug report, or something with Mozilla on this. But to be honest, I'm not sure it would do any good as there are so many outstanding AppleScript/Firefox bug reports out there. Shame on me for that attitude, but if you look at the bug reports you'll see enough unassigned, unfixed, unattended reports to take the wind out of your sails.

Perhaps this blog post can, at minimum, raise some awareness on the topic. In no way do I wish to insult any developers over this. The Mozilla team is doing everything they can to get 3.0 out the door. I just wish AppleScript support didn't go from "okay, it sorta works" in FF2 to "uhh, now it's broken" in FF3.

Let's look at a couple things:

1. Getting the URL and Title of the current tab, or front window (which can be the frontmost tab).
2. Getting general window properties.

I'm going to start with #2 since it shows a regression right of the bat with Firefox 3.

Tell application "Firefox"
properties of window 1
end tell

The result in Firefox 2 is this:

{«class pObT»:window, «class pTit»:"MozillaZine Weblogs", «class curl»:"http://weblogs.mozillazine.org/", index:1, bounds:{639, 44, 1440, 809}, «class pLcn»:{639, 44}, closeable:true, titled:true, modal:false, resizable:false, zoomable:true, zoomed:true, «class pNMo»:true, «class pMMo»:false, floating:false, visible:true}

In the result are the Title: "MozillaZine Weblogs", and the URL: "http://weblogs.mozillazine.org/". Fine so far.

Run the same script in Firefox 3 and you get a similar result; however, the Title «class pTit» is now empty. This appears to be a regression since it worked in FF2. FF3's result is below (on a different page, the title of which is "Minefield Start Page"):

{«class pObT»:window, «class pTit»:"", «class curl»:"http://www.mozilla.org/projects/minefield/", index:1, bounds:{0, 0, 1440, 900}, «class pLcn»:{0, 0}, closeable:false, titled:false, modal:false, resizable:false, zoomable:false, zoomed:false, «class pNMo»:true, «class pMMo»:false, floating:false, visible:false}

The reason I'm using Minefield is to see if this issue has been fixed (as per the bug filing guidelines). And it's the latest Minefield released today, 3/14 - Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9b5pre) Gecko/2008031404 Minefield/3.0b5pre

If you are running Minefield, you'll want to replace "tell application "Firefox" with "tell application "Minefield"...

Okay - next run this script to get the URL of the current tab/window:

tell application "Firefox"
set Link to get «class curl» of window 1 as text
end tell

and/or to get the Title of the page:

tell application "Firefox"
set theTitle to «class pTit» of window 1
end tell

Your results in Firefox 2 will yield the URL and Title of the tab/window. In Firefox 3 you will only see the URL since the Title is yielding a null result.

Okay so far? Nothing broken other than the Title call in FF3, right?

Now I want you to add a System Events call. Let's copy some text. Highlight some text on the page in FF3 and run this script:

tell application "Firefox"
tell application "System Events" to keystroke "c" using {command down}
delay 0.3 (* or no delay *)
set clipText to (the clipboard) as text
end tell

How'd it go? The script should work fine.

HOWEVER, try the previous script(s) now - to get the URL and/or Title of the page.

Did it break? Breaks 100% of the time for me. So it appears that FF3 window properties get hosed after running a System Events call. Once done, Firefox rejects any further AppleScript calls for Title, URL, window properties, etc.

This is the AppleScript error I now get running the "get URL" script:

"Minefield got an error: Can't get «class curl» of window 1."

This is the error from the "get properties" script:

"Minefield got an error: Can't get every property of window 1."

It is very odd here because I can still run the "COPY highlighted text" script with the call to System Events, and I can also run "tell Firefox/Minefield to activate" only the calls to Firefox/Minefields window elements are broken.

My system info:

OS X 10.5.2 on a 1.33GHz PowerBook G4, 1GB RAM running a NEW profile for Firefox. I've even deleted all .plists, Library references, etc., thinking this was related to something stuck somewhere - so I started from scratch and can replicate this every time. Works fine until a System Events call is made.

I do now know if these errors occur on Intel Macs.

Based on what I've gathered on the web and in the Mozillazine forums, AppleScript is simply not a priority for the Firefox project. And that's too bad.

I've extolled Camino's scriptability, and I know Safari has it in spades, but Camino needs the plug-in architecture of Firefox. I've written scripts to enhance Camino and Safari, but even with the scripts, they just don't compare to the breadth of plug-ins offered by Firefox (for me and my workflow).

Safari, for all its good, bogs down on too many web sites and gives me the ol' spinning beach ball more times than not. I hit several hundred web sites every day for MacSurfer and the one browser that has handled the stress with minimal memory leakage and great efficiency has been Firefox. Camino would be next in line, then Safari.

Yes, I have tested all the latest WebKit and Camino nightly builds - as well as the latest Minefield nightly builds (the script problems still exist).

Finally, I've looked for, but cannot find any information on how to (within AppleScript) run a "do shell script" call to Firefox to backdoor a solution for getting "document.URL" or "document.Title", etc. There's no "do JavaScript" command as there is in Safari, but I wonder if there isn't some way to get that info in the shell, and call it from an AppleScript? (And no, javascript bookmarklets do not help. I need to do this via AppleScript).

Thanks for reading through to the end. If you have any thoughts or know of "do shell script" methods to get the URL and Title of a window, or know why Firefox is broken as I've detailed above, leave a note in the comments.

How To: Re-open Closed Tabs in Camino & Safari with AppleScript

Rather than update my previous entry on this topic I decided to write a new one since much has changed.

First I'd like to acknowledge Lisa Thompson for her AppleScript expertise, and code contributions. I have adjusted my scripts to use some of her ideas, with permission. As well, Lisa has some excellent AppleScripts for Camino, including her own rendition of the scripts you'll find here. While I lean more toward keyboard shortcuts and apps like FastScripts, Lisa looks to use a new feature in Camino 1.6 - that of adding scripts to the toolbar menu. (note that my scripts can also be used in the toolbar, but mine also tend to have a bit more stuff - relating to keeping certain windows open, etc.).

If you are a user of FastScripts, iKey, Keyboard Maestro, etc., and you like to launch scripts with keyboard shortcuts, you'll find these scripts handy.

Objective: To give Camino and Safari the functionality of automatically saving the current URL of a tab, writing that URL to file for later retrieval, if desired. If the tab was closed accidentally, using the second script, one can reopen that URL in a new tab.

(Note: Saft already provides this functionality in Safari; Saft costs $12. In addition to reopening closed tabs, Saft also retains the history of said tab. These scripts do not retain the history of the closed tab, merely the URL of the tab at the time it was closed. To my knowledge, nothing like this exists as a plug-in on Camino.)

(Note: The "Save|CloseTab" and "Save|Prevent|CloseTab" scripts save ONE URL at a time. So if you want to go back to a tab you closed earlier, but have open/closed tabs since, these will not work - yet. I am looking at the possibilities of implementing that down the road.)

Background: Why did I do this? As a heavy-duty user of Firefox, I rely heavily on the Tab Mix Plus plug-in which retains tabs (with history), freezes tabs, and much more. But Firefox can get bogged down over time, or sometimes I just want to change browsers for a while. Whenever I switched to Camino for a breather I was amazed at the speed difference, yet discouraged at the lack of Firefox-like plug-ins (specifically Tab Mix Plus - hereafter "TM+").

So a few weeks back I decided to write an AppleScript a solution. I have found it so useful that I thought to share it with others. Perhaps these will be of help to you as well.

(Note: Very important to understand that these scripts do not help if you use the close button located on the actual tab, or if you take your mouse up to "File > Close Tab" or "File > Close Window" - those actions circumvent the AppleScripts).

Usage: When I'm browsing and close a tab (using Command W) that I wish to reopen, I simply hit Command F12 to reopen it. Why Command F12? Simply because it's the default key combo used in TM+. You can use something else if you prefer.

The CloseTab scripts are editable, once open, you'll see my notes as to what/where.

BOTH Save|CloseTab scripts will create a file in the root of the Sites folder. Camino's file is "UndoCloseTab-CAM.txt", Safari's is "UndoCloseTab-SAF.txt". Those text files will open/close automatically when called - you won't see anything, it's all in the background.

HOW-TO:

1) Put the AppleScripts in the folder of your choosing (For FastScripts, use the FS menu, Open Scripts Folder. Inside Applications, if not already there, create a "Camino" and/or "Safari" folder and place the scripts in the appropriate folder(s).
2) Open FastScripts (or your app of choice) and assign the key combo of "Command W" to the "CAM•Save|CloseTab" or "SAF•Save|CloseTab" script (or to the "Save|Prevent|CloseTab" scripts).

(Note: You'll want to assign keystrokes to a specific application. FastScripts, QuicKeys X, Keyboard Maestro, iKey can all do this. Make sure you're not assigning "Command W" as a global command, otherwise that combo will break in other apps. So just assign it to Camino or Safari.)

3) While in FastScripts, assign Command F12 (or other combo) to the "CAM•UndoCloseTab" or "SAF•UndoCloseTab" script.

There are more specific editing instructions in the CAM/SAF UndoCloseTab scripts.

Camino Scripts: (these scripts are for Camino 1.6)

1) "CAM•Save|CloseTab" (only saves/closes tab, does not prevent particular tabs from closing)

2) "CAM•Save|Prevent|CloseTab" (this saves tab URL, looks for page title of user-specified page and prevents closure of said tab, and also prevents last tab from closing)

3) "CAM•UndoCloseTab" (does what the name says)

Safari Scripts:

1) "SAF•Save|CloseTab" (only saves/closes tab, does not prevent particular tabs from closing)

2) "SAF•Save|Prevent|CloseTab" (this saves tab URL, looks for page title of user-specified page and prevents closure of said tab, and also prevents last tab from closing)

3) "SAF•UndoCloseTab" (does what the name says)

That's it. Enjoy browsing with a little safety net below ya. :-)

If you're an AppleScript guru and have suggestions, I'm all ears, so please drop a note in the comments.

Camino, Safari - How-To: Reopen Closed Tabs (with AppleScript)

Firefox has been my browser of choice for many reasons. First up on the list would be add-ons. I run several extensions, but my favorite - by far - is Tab Mix Plus. It allows you to freeze a tab preventing it's accidental closure. If you happen to close a tab and want to reopen it, you can - complete with the tabs history in tact.

But Firefox has its own quibbles. Tab Mix Plus can slow things down a little GUI-wise. At least that's been my perception. And Firefox is not exactly Mac like. Firefox 3 is looking great; however, AppleScript is not working as well in 3 - and if you know a fix for getting the URL of an existing page, I'd be most appreciative.

This used to work:

tell application "Firefox"
set Link to «class curl» of front window
set theTitle to «class pTit» of front window
end tell

Neither the «class curl» or «class pTit» work in FF3.

So on to Camino - it is awesome, faster than Firefox, but is not expandable with add-ons in the same manner that Firefox is. Tab Mix Plus is sadly missing.

So I put my brain to work and came up with a partial solution. I say partial because I cannot restore the history of a reopened tab, and these scripts can only restore the immediate last closed tab, not the last several tabs as in TMPlus.

These scripts work with Camino 1.5, but will need modification to work with v. 1.6 - which I do not have installed. Will update when 1.6 is out of beta.

I use the scripts in conjunction with FastScripts assigning the script the CMD-W keystroke overriding Camino's cmd-w. So when you use "cmd-w" to close a window, the script runs, copies the URL of the current tab to the clipboard. If you want to reopen the closed tab, hit "cmd-F12" or whatever key combo you assign and presto, it reopens (NOTE: if you have copied something to the clipboard AFTER you closed the tab, this won't work - this solution is for an "oops, I didn't mean to close that window" type of scenario! Also of note, this will NOT work if you use the close tab button.).

Here's the CMD-W script - I call this script "CAM-CloseTab(CmdW)", assigned keystroke "Cmd W" in FastScripts:

------- Script cut/paste below into new script ---------
tell application "Camino"
activate
set Remember to URL of window 1 (* Camino 1.5 *)
set the clipboard to Remember
(* BELOW - is if you have a site(s) you want to prevent from closing - replace XYZ with the TITLE or part of the TITLE of the page. Thus when you click Cmd-W, this site will not close *)
if name of front window contains "XYZ" or name of front window contains "XYZ" then
tell application "Camino" to activate
else
my closeTab()
end if
end tell

(* Tab Handler *)
on closeTab()
tell application "System Events"
tell process "Camino"
click menu item "Close Tab" of menu "File" of menu bar item "File" of menu bar 1
end tell
end tell
end closeTab
-----End Script----

Here's the Reopen closed tab script - I call it "UNDO Close Tab", assigned keystroke "cmd-F12" in FastScripts:

tell application "Camino"
set Remember to the clipboard
open url Remember (* Camino 1.5 *)
end tell

It is worth noting that some of this syntax will change with Camino 1.6.

This can be done with Safari as well, here's the scripts:

Assigned in FastScripts as "Command W":

tell application "Safari"
activate
set Remember to URL of document 1
set the clipboard to Remember
if name of window 1 contains "XYZ" or name of window 1 contains "XYZ" then
activate
else
close current tab of window 1
end if
end tell

Reopen closed tab (assigned in FastScripts as cmd-F12 keys):

tell application "Safari"
set Remember to the clipboard
open location Remember
end tell

If you see something that could use tweaking or such, drop me a note in the comments.