10 posts tagged “web”

Aral Balkan is trying to run the website for his conference on Google App Engine, the same platform that snaptrip uses. In October, he posted twice on Twitter:

Great, you have no control over how Google App Engine caches data requests. Pulling in RSS feeds? Forget about it! (It uses Google Proxy and you can't tell it not to cache a feed or set the cache duration.)

I'd also noticed this, because the snaptrip login page (which does double-duty as an FAQ and news page - maybe I should rename it?) pulls in entries tagged 'snaptrip' from the Atom feed of this very weblog, and after my third post it failed to update for a good half a day. I wasn't that bothered, and didn't bother to double-check the documentation, which does clearly state that

App Engine uses a HTTP/1.1 compliant proxy to fetch the result.

Evidently this is the same problem as Aral has, and as usual, Tom Insam had an answer. It's from a slightly different direction (working with Google's Open Social containers), and as he said, it's what "everyone has done for years to bust caches you don't control": append an incrementing (or random) parameter to each request, which should mean that you're not hitting the cache. Having finally written a new blog post about snaptrip, I can confirm that this approach works. I'm not sure I'll leave it in - it seems a bit rude - but if timeliness is important, you might want to do the same.

It also occurs to me that, if every call to urlfetch is cached for some time, then you may find that repeated calls via API libraries might give somewhat unexpected results (although they're more likely to have changing arguments, anyway). Be careful out there.

Last week Safari 3.2 was released, with the usual minimal release notes: "This update includes stability improvements and is recommended for all Safari users." The security notes were somewhat more forthcoming, but even there, not everything is covered, for as well as bug fixes, 3.2 quietly added support for two big security features: EV SSL, and Google Safe Browsing.

Neither of these changes, obviously, is covered in the release information, but since the (very good) MacJournals writeup of details of the anti-phishing features was reposted at Macworld, there's been a small whirl of further commentary, especially as the latter includes data collection for Google. Most of the (sensible*) concern has been raised because Apple's terms and conditions, unlike those of Firefox (who also use the Google Safe Browsing API), allow Google to make use of the data sent as a result of surfing using this plugin for any purpose, not merely enhancing that particular service. This might not be so bad if it wasn't also for the fact that the Safe Browsing checks fetch and send data by default.

Personally, though, I can't say I'm bothered by either of these. I'm sure Google get far more useful information from searches and opt-in service usage than they get from partial hashes returned when browsing to potentially hacked sites. As for defaulting to using the service, well, both Chrome and Mozilla also do that, and as with Firefox, Safari offers a preference to disable phishing detection.

What is more surprising to me is that so few people have connected the release of 3.2, and its emphasis on security over features, to the removal of Safari as a "safe" browser from Paypal's list in February:

"Apple, unfortunately, is lagging behind what they need to do, to protect their customers," [PayPal security chief] Barrett said in an interview.

I have little doubt that there's been behind-the-scenes back and forth between PayPal, and similar organisations pushing these changes, led Apple to release this sooner rather than later, in the 3.0 branch (rather than waiting for Mac OS X 10.6 and Safari 4.) Perhaps a more sensible place for people to raise questions is whether EV-SSL and Safe Browsing are actually useful, or if they're merely security theatre? Now there's a well-researched comment piece I'd like to see.

* There's also a lot of kneejerk "OMG Google haz my datorz!" nonsense, but reading the article makes it clear that only hashes of URLs are checked, and even that's only when a partial hash is matched against a hash of your current URL.

Long-time readers here may remember groupr. (If you don't, it was a small web application that loaded the photos in your Flickr groups, something that, oddly, you can't do on Flickr itself.) I wrote it at the beginning of 2007 for Fotango's Zimki platform. Of course, when that died at the end of last year, groupr vanished, but not before I took a backup of the code and templates underlying it, in the hope that one day I might be able to revive it.

For a few different reasons, I've been considering bringing groupr back recently. I could use Google's App Engine, as I've done for snaptrip, but that was from scratch, and for this project, I didn't fancy porting both the code and templates. I had a quick look at Helma and Trimpath, but I didn't get on with either of them. There's also the fact that they they're not hosted solutions, and part of the joy of server-side JavaScript (SSJS) is not having to worry about finding a server. I also tried Reasonably Smart, but you have to be pretty clever to get git working, and I couldn't, so that was out.

Eventually I found AppJet, and after a quick look I was convinced that this was probably a good place to end up, and after about eight hours to port what I had, and another five or so to fix up some things I never quite polished off on the old version, you can now use groupr.appjet.net.

So, how does it compare to Zimki, and how hard was it to port the code? (After all, big names are now talking about portability in the cloud). Well, AppJet may be closed source, but they offer a downloadable JAR which ran without any effort for me on Mac OS X, meaning both that I could develop locally (even offline, with cached data), and that if AppJet vanishes (which, after all, happened to Zimki) I can take groupr and run it on a server of my own. In this case, practicality trumps theoretical openness.

AppJet's IDE feels a lot nicer than Zimki's did (although I barely use (or used) either, preferring BBEdit with AppJet's JAR, or Trawler for Zimki). I also approve of the way that libraries are handled (they're just apps whose name includes the 'lib-' prefix) is pretty nice. You can see what is using a library and there's provision for inline documentation too. The community feels bigger than Zimki's ever did (although that might just be because the idea of SSJS is taking off), and I was able to find a few useful libararies (such as a TrimPath template port) pretty easily. Speaking of libaries, AppJet's 'storage' is oddly non-core, but it's a pretty nice row-style store with nice querying facilities. It lacks Zimki's handy "expires:+2h" syntax, but that wasn't too hard to fit in myself.

One definite annoyance I have with AppJet is that they don't keep all their libraries out of the global namespace. Zimki's functionality was all hidden in a zimki object, but AppJet has a few top-level standard libraries, and 'page' and 'response' both clashed with names I was using in groupr's previous version. Another is that there's no way of handling non-JavaScript files, so both static files and templates are tricky. I've ended up with the former being hosted on my main server, and the latter as a hash of triple-quoted strings (a Python-ism that AppJet has imported into their JS runtime). Proper file support, like Zimki had, would be a boon there. However, both of these were pretty easy to overcome, and it turned out Zimki did very little that AppJet couldn't replicate. (Replacing the (Mojo, I believe) API calls was four lines of jQuery; replacing the server-side API cleverness, for my needs, was a few lines of JSON.)

Overall, then, I think I'm pretty happy with my experience so far. I've managed to revive the project without too much hair-pulling, and, as I said, even extended it from the state it was in on Zimki. Maybe server-side JavaScript has a future after all?

Earlier this week, I published a post entitled Hackability: Gecko vs WebKit. Actually, it sort of snuck out in the middle of the night; as is my wont, I left it as a neighbourhood-only draft overnight, only to find that Simon had turned up and made some of the points I was going to go back and edit in as a comment. Since nobody ever reads comments on the internet, and also since Simon, Tom and myself had a bit of a discussion on the subject on IRC, I thought I'd follow up the post with some further thoughts.

Firstly, Simon made further mention of Gecko 2, the next-big-thing coming from Mozilla. It does sound like it's going to be a great deal of work, and that it's probably dumb for them to be gung-ho about fixing some of the Acid3 issues in the 1.9 branch when 2.0 is around the corner. On the other hand, the very fact a 2.0 is needed is a bit worrying, and I'd also argue that perhaps there should already be a code branch being worked on. In comparison, I strongly suspect that the WebKit team have been lucky enough to time any major reworkings of their codebase to be out of the public eye.

Secondly, Gecko and WebKit both turn out to be about the same age- nearly ten. Admittedly, KHTML was initially much more minimal¹. On the other hand, this turns out to be key to the point I really should have made in the first post.

One of WebKit's stated project goals is hackability. In contrast, Gecko's layout engine doesn't really have a project page; the closest thing there is to one admits that

much of the code for the cross-platform toolkit is mixed in with this code, it is described elsewhere

This is really, I suspect, where the two projects diverge. WebKit is designed as an embeddable renderer. It's pretty modular - one of the KHTML legacies is that the JavaScript implementation is separate, as you can see from the fact that Quartz Composer embeds JSCore but not WebKit. It does one thing, and does it pretty well. (The same is somewhat true of the most common browser using it, Safari.) Given this, it's no wonder that it's adding features and passing tests at a rate of knots.

In contrast, Gecko is part of Mozilla's platform. It's a fairly major part of XULRunner, a cross-platform application framework that hosts Firefox, Thunderbird and other apps. That makes it big and gnarly, and probably makes it harder to work with, but it also offers a great deal of flexibility. Firefox is so extensible because the UI is itself written in a markup language, and it can be modified and extended without learning (too much) new stuff. In contrast, there are no supported ways to extend Safari's interface².

So far, I think we all agreed. Different goals lead to different priorities, and as Simon put it:

Teams focus on different things. saying "Well it's Apple's policy not to do plugins" is like saying "It's Mozilla's policy not to spend resources on what could quite reasonably called a PR exercise" but, as we know from Perl, PR exercises and easy hackability keep a project alive.

Where we parted company was that Simon argued one of the keys to the success of Firefox was this extensibility. Since it comes at a cost, it would be good if one could argue that it had also had a benefit. Unfortunately, personally, I doubt that the success it's managed against IE (which, compared to the market share of its prehistoric ancestor, Netscape Nagivator, isn't actually that good - although numerically I'm sure Firefox has more installs than Navigator ever managed) has anything to do with extensibility. Do real people install extensions - even lauded ones like Firebug and AdBlock? Somehow, I doubt it.³

No, the success of Firefox is down to offering a familar enough UI (Opera fails here, however compelling the features are once you get through to them), free (again, until recently, an Opera weakness), and with better security than IE (perhaps less so now, but older versions of Microsoft's browser didn't get their reputation for nothing). That's not to say that the work on XUL isn't good - extensibility helps get geek mindshare, just like passing Acid tests - but again, I do wonder if it's costing more than it's worth. After all, if easy hackability keeps a project alive, what does a lack of the same do?

¹ A fair chunk of the discussion was about how KHTML and WebKit were related. I don't think it's particularly relevant here and nobody bothered with the relevant Slashdot forensics, so I'm going to skip it.
² Hopefully that wording is clear enough to be understood as meaning "things that aren't browser plugins". I believe that none of the other WebKit based browsers offer much of a UI customising API either.
³ I'm more willing to believe they install themes. Shudder.

This post has been brewing for a while, but I've been prompted to actually write it by seeing John Gruber's offhand remark on his most recent linked list entry, about CSS gradients in WebKit:

Just me, or is WebKit racing way ahead of Gecko in terms of support for cool new stuff?

No, it's not just him. WebKit, and Opera's layout engine Presto, raced towards Acid3 compliance in March, with both effectively reaching a photo finish on the 26th. Meanwhile, Microsoft hasn't even shipped a non-beta Acid2 passing browser¹; no surprise there. But where's Gecko, the Mozilla layout engine, the one that powers Firefox?

Well, to be blunt, it doesn't look as if they care much. We have one developer saying that Acid3 is basically worthless, and another (more diplomatically) stating that it's a missed opportunity and an exercise in making browsers jump hoops, rather than improve "real" functionality. As others (almost certainly more qualified than I am) have noted, this sounds a lot like the noises from Microsoft around the time of Acid2's release.

The thing is, I'm not here to kick Gecko, but to understand its problems, if it has them. Does the team's response to Acid3 mean it does? Possibly not on its own, but coupled with events like the move of Epiphany to WebKit², and the aforementioned speed of development on WebKit (and to a lesser extent Opera's Presto³) I have to wonder. Why is development there so slow?

One stated reason is that the Mozilla Foundation is on a rush to release Firefox 3, and it's certainly true that it is coming up for release. On the other hand, Apple certainly seem to be able to keep the open-source WebKit tree distinct from the version used in releases - Safari 3.1 shipped with an Acid3 score of 75 when nightlies were scoring 90-odd - so I should hope that's not the real reason. Maybe they're pulling people off the layout engine to work on the browser? That's not as stupid as it sounds for most apps, given the way the Firefox UI is set out using XUL, a markup language. Even so, it feels like a bad use of engineering. Maybe Gecko's reached that point where extending it's no fun. The language the team themselves uses, with talk of Gecko 2, makes me wonder if that's true.

I don't have answers, anyway, but I'd love to hear from people who do why Gecko is giving the appearance of stagnation, while WebKit seems full of life.

¹ Bafflingly, it seems that Microsoft develops not one, but four layout engines: Trident, for IE/Win, Tasman, originally for IE/Mac and now part of Office:Mac, and two unnamed engines, one in Word and Outlook 2007, and another in Expression Web Designer.
² Admittedly that's got contributing factors beyond merely Gecko; it sounds like the wrapper they were using to embed it (GTKMozEmbed) had some seriously nasty issues of its own.
³ I mentioned to Tom Insam that I was surprised I'd never heard of the name of this engine, but he sagely noted that, as it's not open source or embeddable, there's no reason I would have.

Until now, online communication has lacked personality, being limited to text (IM, SMS, email). Seesmic changes that, bringing conversation alive through video

"At last, the Internet is really social: you can see and hear people express their ideas and thoughts, you can join in, and you can make new friends. With Seesmic, everyone can participate in live conversations rich with personality, bought to life through video," commented Ron Conway

The subject of attribution on the "image bookmarking" site ffffound has been getting a bit more attention recently. For example, it's a key point in Alexander Bohm's reconsideration of the site. With the site's slow but relentless increase in popularity, I've come to notice duplicate images on the front page more and more often. (One that particularly bugs me is this early sketch of the Underground roundel, which I posted from the IHT, but which was later posted without the annoying black border via fontblog.de.)

Personally, right back to the early days of blogging (a whole five years ago now), I've tried to remember to chase back attribution as far as I can, and I do this with images on ffffound, too. Today I saw this house on the front page (linked, annoyingly, to the blog's home page, rather than the post's permalink- the sort of thing that makes it impossible to trace attribution once the page's cycled, which can be as quickly as a few days, but never mind that now), and so I read down the page looking for other posts* of interest.

Rapidly I found this Moleskinerie hack, which, unusually for such things, I quite liked. I followed the attribution change back through designboom (again, having to find the permanent link myself - are all designers incapable of doing this?) to the original artist's site (once more a link to the top level, which is more excusable this time, since the post was about his entire body of work). At each step I posted the same item to ffffound, generating three links, each addded by different people. It turns out that the least popular (two links, at the time of writing) was the artist's site; the two blogs had three links each.

ffffound doesn't really try to tie these images together, or to do anything to limit the duplication. Admittedly, sites like del.icio.us don't either, and variant URLs on the same site can lead to as much duplication as the quoting (and reuploading) of images can. Nevertheless, it's a source of annoyance to me, and, I assume, even more vexing to those whose work is never recognised, because it's referred to but never seen in the context they'd prefer, or attached meaningfully to its creator.

* I've got a rant brewing about the use of "blog" to mean "blog post" as opposed to "site", but never mind that now either. Anyway, I fear that the battle's already lost, despite me only noticing the trend a month or three ago.

There have been a couple of posts since Apple's press event on Tuesday, which saw the launch of the new .Mac Galleries - an online, read-only version of iPhoto, kind of - that state that "Apple doesn't get the web". Jeremy Keith says

in the fast-moving, messy world of online services I don’t think the genius-led design of Apple can compete with the truckloads of nimble young upstarts making snazzily addictive products on the Web

and Chris Heathcote writes

Whenever Apple strays towards software and the web recently, there’s a lot of flashy interfaces, and little substance.

I think there's a slight qualification to be made here. I think Apple are great at web publishing. Their site is one of the best product sites I've seen (despite the fact I dislike the new bigger-than-800-pixel width). I've been going on about the elegance of URLs - it's possible to guess that there's something at apple.com/keyboard, for example - since 2001 or something, and even when they drop in AJAX their pages still have usable permanent links.

When designing for consumers, Apple takes the same approach. They produce tools for publishing, using a one-to-many, one-direction mode of thinking. As James Duncan Davidson notes as he writes about the .Mac galleries, "It’s not Flickr, and comparing it to Flickr is probably pointless." Well, no. Flickr is the archetypal Web 2.0 application, being almost as much about community as about photographs themselves. The .Mac gallery, on the other hand, is all about putting your work online. There's no comments, no notes, no tags, but the people who it's aimed at don't want that. They're about publishing, not interaction, and while they pages are undoubtedly heavy, and probably scale badly, they're also slick enough that a lot of people will like them.

Similarly, iWeb-generated blogs have no comments, but well-designed templates (from which it's hard to stray.)* Again, it's designed for publishing. The problem for Apple is that it's not 1999 any more. People expect more from their sites now, and thankfully more and more of the sites I use are applications, not brochureware. So perhaps the statement needs to be refined, because despite the JavaScript libraries and slick visuals, Apple doesn't get Web 2.0.

* One point where iWeb fails is that it doesn't preserve Apple's nice URLs; the ones it generates are distinctly ugly. At least, they were in the first version.

Recently the Cocoa development bloggers have been abuzz with talk of ObjC, Ruby, Python and Cocoa. (I could worry about the fact Perl's not in that list, but I Sherm's done as good a job as he could given the relative lack of community support; I'm sure the underlying "object model" didn't help either).

It was only on reading this post on Theocacao, though, that I realised that (one of?) the starting points for this whole discussion was John Gruber on the Hivelogic podcast. Now, I'm not a big podcast listener. I can't code while listening to speech, so it's out when I'm in front of a computer at home and work, pretty much. There's Radio 4 for when I'm in the house away from the computer, and my commute's not really long enough for them either. Unless there's a transcript, in other words, all I know about podcasts is the shadow they leave in the textual web.

Similarly, I've not listened to the Backstage podcast on DRM and iPlayer, but there's a lot of follow-up material that I can read. Meanwhile, Monocle's web presence seems to spurn text in favour of video and audio, which means that I can't easily point out the part of the interview with the Lego CEO where he talks about Harry Potter being a less successful licence than Star Wars, nor can I rely on it as an archive (unlike, say, the Economist's site).

On Friday, Chris Heathcote was suggesting that our generation - the one that grew up with a textual internet (including the web) might be the odd ones out. If you're ten years older, your media landscape is dominated by (broadcast) radio and television. Ten years younger and podcasts, embedded Flash video and multimedia-heavy websites dominate. In the middle there's us stubborn holdouts. Some of us remember Usenet as a golden age, others the early years of blogs, but we're united by being primarily text-based, but things are changing.

I'd argue it's a great loss, but maybe that's just because the tools to annotate, mix, and link together audio and video aren't there. (Let's face it, weblog permanent links took a horribly long time to show up). On the other hand, it's possible I'm just being a grumpy old man.

For the last couple of months I've been sitting on a CGI script that would aggregate all my content for my personal site. Part of the reason is caching: the script doesn't have any, and it turns out that XML::Feed isn't Storable friendly, which knocks out my first approach.

So when I had a think about what Yahoo's Pipes promises, I thought it might be worth a look. I could get the service to do all the heavy lifting, hope they had a sensible caching policy (and if not, well, at least it was Someone Else's Problem), and then just format a single RSS feed locally.

Sadly, there's a major problem. The aforementioned XML::Feed Perl module does a wonderful job of hiding the mess of formats that labour under the acronym RSS and the name Atom. If you want to soft by date, you can do so easily.  (In fact, you get lovely Perl DateTime objects. I can't sing DateTime's praises enough, even if it does look daunting at first.) Pipes, however, doesn't. I can sort my Vox Atom feed by its pubDate property, or my delicious and husk RSS feeds by dc:date, but neither sort has a date format in common, so I can't sort them once they're output.

I had a quick look to see if there was an obvious way of doing a date transformation on an element of an item, but unless I'm missing something it's far from obvious. I could write a small web service and call it, but that's a lot of work, and I might as well do things locally if I'm that bothered. So I've given up, but not before writing this, because it seems like a natural thing to handle in such a high-level environment, and I'm surprised they don't.