Posts tagged “uploadr”

Dopploadr at Yahoo! Open Hack Day 2008/09/14

My hat's off to Yahoo! for putting on a great show this weekend. More than one person told me how much more excited they are about Yahoo! after experiencing Hack Day. It really does bring out the best in everyone. Plus, the Girl Talk set Friday night was killer.

MikeD and I showed up proudly wearing our OpenDNS t-shirts and were taken aback by the number of excited OpenDNS users we encountered — thanks, guys. Mike did the vast majority of the work on our main hack, a reworking of the OpenDNS Guide to use Yahoo!'s BOSS search API. We're excited about the prospects of integrating our user's preferences directly into search results. My part in all of this was to wrangle the markup and CSS. We really could roll this out next week and we wanted it to look that way. In the demo, Mike mentioned (casually) that we could throw a few million queries per day at BOSS. We aren't kidding.

Enough OpenDNS, tell me about the cheating

Before I sat down to crank out the eye-candy for the OpenDNS Guide, I built an extension for the Flickr Uploadr. But I wrote the Flickr Uploadr. This is totally cheating. I'd like to think that the Flickr judges felt the same way and that's why I didn't win any prizes but it doesn't matter because some people I really admire graciously complimented my work and I expect it will see quite a bit of day-to-day use. I hope it can also serve as a good starting point for future extensions. Without further ado:

Dopploadr

Dopploadr is an extension for the open-source, Mozilla-based Flickr Uploadr. As I said in the demo, it works just like a Firefox extension because it is. The Uploadr includes Mozilla's Extension Manager.

Once you install Dopploadr, Uploadr will take you to Dopplr to authenticate. My apologies for the copy & paste step but there's no equivalent of flickr.auth.getToken in the Dopplr API. One other catch that should be mentioned is that Dopplr's API must be accessed over SSL and (at Yahoo! and during my demo, at least) their servers or certificates frequently and randomly fail. Try again.

Once you're authenticated, there's really no UI to it. The status bar will indicate you're signed in, saying "Dopploadr for rcrowley" or some such but the real magic happens behind the scenes. Each time Uploadr thumbnails a photo, it hands off the date-taken field during the after_thumb event and Dopploadr decides where you were at that time, noting the latitude/longitude and some tags like:

When you upload a batch, Uploadr will again be really secretive but Just Work. The before_one_upload event will combine the user's tags with the geo tags above and then let Uploadr continue with the upload. When Uploadr finishes, it hands off the photo's ID to Dopploadr during the after_one_upload event so Dopploadr can call flickr.photos.geo.setLocation with the stored latitude/longitude.

My official monkeypatch count sits at 3. First was adding the after_logout event that I still haven't actually used (see also version 0.2). Second was a short walk around the DOM to insert Dopploadr's string bundle (strings accessible from JavaScript). Third was adding a counter for outstanding Dopplr API calls and making the buttons.upload.enable() method sensitive to the count to prevent uploading before everything's been geotagged.

Here's the photo I uploaded during my demo: http://flickr.com/photos/rcrowley/2853699765/. (See, it really works!)

You can download Dopploadr 0.1 or check out the code on GitHub.

My sincerest thanks once more to the folks all over Yahoo! that made Hack Day happen.

Comments (9)

Uploadr extension extensions 2008/09/07

Getting re-acquainted with Flickr Uploadr, I discovered a sorely missing piece of the Extension API. There are plenty of hooks to catch higher-level events than clicks and mouseovers — things like logins, uploads and adding photos. However, there is no way to store persistent data and associate it with a certain Flickr user. Here is a way:

var userinfo = {
	set: function(k, v) {

		// Only allow userinfo if they're signed into Flickr
		if (!users.nsid) { return false; }

		// It's just a hash for storing whatever you want
		var u = users.list[users.nsid];
		u.userinfo = u.userinfo || {};
		u.userinfo[k] = v;

		return true;
	},
	get: function(k) {
		if (!users.nsid) { return undefined; }
		if (!users.list[users.nsid].userinfo) { return undefined; }
		return users.list[users.nsid].userinfo[k];
	},
	unset: function(k) {
		if (!users.nsid) { return true; }
		if (!users.list[users.nsid].userinfo) { return true; }
		delete users.list[users.nsid].userinfo[k];
		return true;
	}
};

Another thing I found missing was an after_logout event. So I monkeypatched one:

users.old_logout = users.logout;
users.logout = function(save) {
	users.old_logout(save);
	extension.after_logout.exec();
};
extension.after_logout = new extension.Handler();

extension.after_logout.add(function() {
	Cc['@mozilla.org/consoleservice;1'].getService(Ci.nsIConsoleService)
		.logStringMessage('after_logout!');
});

T-minus five days and I've got my development environment ready to go. I'll be at Yahoo! Open Hack Day September 12-13 in Sunnyvale, hacking on Uploadr. Hopefully others will join me in creating some cool extensions. Stop by and say hello.

Comments (0)

When you can't statically link, manifest 2008/01/14

Manifest (verb): To embed XML describing libraries which are expected to be available at runtime, done in the course of developing software using Microsoft Visual Studio.

The wisdom of the collective T-Rex (#xulrunner on irc.mozilla.org) says that statically linking against the Microsoft C Runtime (msvcr80.dll and friends) is the way to go. However I've run into a case where I cannot do this (deciding whether this is due to technical limitations or lack of competence is for readers to help me decide).

The image processing component of the Flickr Uploadr links against GraphicsMagick and Exiv2, libraries that do image processing and EXIF/IPTC metadata processing, respectively. Without them, it doesn't fly. Problem is, they both link the C Runtime themselves by using std::string and such. Both of these libraries will build fine given the /MT flag, which instructs them to statically link the C Runtime. When they themselves are statically linked into the XPCOM component later, all hell breaks loose. It seems that the static linker can't resolve the duplicate definitions caused by overzealous static linking.

The solution, as it stands, is simply to include the C Runtime and its manifest in the distribution. Placing the following files in Uploadr's components/ directory has allowed life to go on for the moment.

Lastly, make sure your XPCOM project in Visual Studio is set to embed its manifest from Project Properties » Manifest Tool » Input and Output » Embed Manifest.

A more optimal solution might be to combine the Visual Studio projects for GraphicsMagick (and therefore libjpeg, etc), Exiv2 and the XPCOM component into one large tree that Visual Studio might be able to better manage. Has anyone out there done such a thing with Microsoft's static linker (even if not with XULRunner)?

Comments (3)

Flickr Uploadr 3.0 lives 2007/12/20

Time to take a deep breath. Flickr Uploadr 3.0 is out for all and two minor revisions later is looking pretty good. There are still issues to be resolved but I won't spend any time here whining about desktop software or how hard it is.

Richard's laptop haulInstead, a couple of lessons I definitely learned the hard way from this release.

The next challenge will be turning the GPL'ed Uploadr into something moldable and bendable for other developers to play with. In the meantime, check out the new Flickr Uploadr and its source code at http://flickr.com/tools/uploadr/.

Photo from Cal.

Comments (4)

Other tags: