This is a followup to my previous post on eMusic’s new prices. In this post I provide the equivalent per-track prices for all products offered in the US, the UK, and the rest of Europe. Although I didn’t note it in the original post, I obtained the underlying plan prices for the US from the description of eMusic’s plans linked to from section 6.1 of the eMusic.com Subscription Agreement; poppi and xtrev provided the corresponding prices for eMusic UK and eMusic Europe from the equivalent list for those services. Those lists are the closest things eMusic has to an official published price list; it apparently includes only plans offered to new subscribers, and does not include any special discounts that might be offered to existing subscribers. ...

Thanks to poppi and xtrev I now have a complete set of eMusic prices for the UK and the rest of Europe as they would apply to new subscribers. (Recall that current subscribers were offered the opportunity to continue at current US prices plus 17.5% Value Added Tax. I’m not yet clear on how that offer actually translates into practice, so I’ll defer discussing it until a later post.) The first table shows prices for all eMusic products in the UK (priced in pounds), together with comparisons with current eMusic US prices; the exchange rate used is 1.90530 dollars per pound, the average interbank rate for August 10, 2006: ...

This is my report on activities of the Mozilla Foundation for the week ending August 11, 2006. Projects for the week Here’s a partial listing of what I and others at the Foundation did this past week: CA certificates. I approved a request from Geotrust to add to their current list of root certificates, as well as a request from Swisscom to add their root certificate. Next action(s): Resume looking at requests from KISA and others. ...

The big news on the eMusic message boards the past day or so is that eMusic is introducing a European version of its service (currently in “beta”). There’s no press release from eMusic, and no prior communication to eMusic users. (However this move was mentioned in an eMusic submission on the topic of DRM made in January of this year to the All Party Parliamentary Internet Group in the UK.) The plus for European subscribers to eMusic is that they should now have access to more music: Previously they were prevented from downloading albums in cases where distribution in the US was handled by a label with an agreement with eMusic, but distribution in Europe was done by another label without such an agreement. Now the eMusic UK subsidiary can do its own deals specifically for Europe. ...

This is my report on activities of the Mozilla Foundation for the week ending August 4, 2006. Projects for the week Here’s a partial listing of what I and others at the Foundation did this past week: Grants. I approved a grant for enhancements to the DOM Inspector UI (this was originally submitted for the Google Summer of Code) and submitted a separate grant proposal to the Foundation board. Next action(s): Get DOM Inspector work under way, take action on other grant proposals as appropriate. ...

This is my report on activities of the Mozilla Foundation for the week ending July 28, 2006. Projects for the week Here’s a partial listing of what I and others at the Foundation did this past week: Security. I dealt with a mistaken report of security problems associated with the file NSSCKBI.DLL, which holds the pre-loaded root CA certificates for Firefox and other Mozilla-based products; for more information see my post to the mozilla.dev.security newsgroup. ...

The mainstream media is beginning to take note of eMusic. The latest sign: a favorable article in USA Today, “EMusic’s pitch: Download song-and own it.” I found the very last section of the article most interesting, describing David Pakman’s attempts to convince major labels to participate: He has a juicy pitch: Give him out-of-print material that consumers can’t get their hands on and let him promote the material heavily on eMusic, minus DRM. . . . The proposal has been accepted at all the major labels by lower-level digital executives, but gets stuck when it goes up to the executive suite, Pakman says. It’s a fun idea to consider, he says, but he assumes it will never happen. ...

My last post illustrated one way to figure out where a company like eMusic is going: look at its job listings. This post shows another way: look at press releases from its key suppliers, in this case a release from Day Software Holding AG (a Swiss vendor of content management applications), “CRX to Store, Manage and Exchange information about Artists and Records on Popular Music Site.” As it happens, this particular news doesn’t seem to have any particular implication for eMusic subscribers, except perhaps to demonstrate eMusic’s investment in creating a reliable high-volume web service. Day’s Content Repository Extreme (CRX) product is a true backend product: As explained in the CRX FAQ, its function is to present a standard interface between the underlying content repository (in eMusic’s case, where all the album and track information is stored) and the front-end content management system (which provides the actual end user interface to the eMusic content). At least in theory this will enable eMusic to change its web front-end (perhaps even migrating to a different CMS) with minimal change to the back-end. ...

This is my report on activities of the Mozilla Foundation for the week ending July 21, 2006. Note that I was out of the office on vacation for most of the week. Projects for the week Here’s a partial listing of what I and others at the Foundation did this past week: OSCON. Zak Greant coordinated with Brian Behlendorf re a brief “lightning” presentation on the Mozilla Foundation at OSCON 2006, but this apparently got dropped due to lack of time in the schedule. ...

UPDATE 2023-03-27: This page is obsolete, as it refers to a prior version of this blog. However, it may be of historical interest. This post introduces the Blosxom plugin “extensionless.” Ever since reading the essay “Cool URIs don’t change” I’ve wanted to change my web site to conform to some of its recommendations, including the recommendation to omit file extensions (e.g., “.html") on URIs. Unfortunately standard Blosxom requires that a file extension be present in a URI for an individual entry (e.g., http://www.example.com/foo.html) to distinguish it from a URI for a category (e.g., http://www.example.com/foo). How to fix this? ...