Cocoa EOF? No thanks
As our current persistent framework at Watershed needs work I’ve been thinking about shared persistent data frameworks
It appears to be with increasing frequency that one can hear experienced Cocoa developers reminiscing about EOF for desktop applications and new developers wondering why Core Data doesn’t use stores in network RDBMS’s from a range of vendors.
As Watershed’s persistence framework will shortly be replaced, I’ve been working on some possible replacements. One of the best things about being an in-house developer is, I get to to see people using my applications every day. I walk past people’s desks and see which windows are open and what tasks users perform. An incredibly frequent task runs as follows:
- The user needs to make a quick edit to an item stored in a relational database.
- The user opens their Cocoa client and a window opens, normally containing a NSTableView listing all the entries.
- The persistence routines generate the required SQL, sends it to the database and receives a stream of data.
- The persistence routines turn the data into a object graph generating thousands and thousands of objects. Each business object, even with relationships represented by proxy objects, contains many attributes each of which is represented by an object.
- Once the persistence routines have finished creating the thousands and thousands of objects, making copies & caches and linking them together by setting object instance variables: the user opens the first item in the list, corrects a typo and quits the application.
The problems evident in the example could be seen as a UI issue. Possibly the way forward is to follow iPhone applications’ methods of display a small number of entries then prompting the user to load then next batch. iTunes displays thousands of tracks in a table on launch so why can’t my applications do the same? The business object implemented using NSManagedObject or an EOGenericRecord is an atomic unit. Why does the application need to populate an entire business object just to display the title in one column?
Caching large chunks of data on the client made efficiency enhancements that were just not needed. Launch times are incredibly slow, damaging the user experince. Worried about excess network traffic, we started off designing clients with aggressive caching. Our controllers in the Cocoa applications now save changes more frequently, and with less modality in the edits. This results in a constant trickle of data across the network but a much smoother user experience.
Public applications with a large number of users render bulky local caches ineffective. As the number of editors increases, the probability that a local cache is no longer synchronised increases.
Frameworks such as EOF or ActiveRecord work very well over high speed, high quality networks but many network connections for Macintosh, and iPhone, clients are mobile and made wirelessly or are intermittent. Many clients connect over fragile internet connections where the performance will destroy the user experience.
So, no I don’t want Apple to re-release EOF for Objective-C or allow Core Data stores to reside in a network RDBMS—I want something better.
Beamer
Broadcasting short films to mobile devices using Bluetooth in the Watershed Café Bar.
As part of 2007's Electric December we wanted to send video films to mobile phones quickly and cheaply. One method selected was to send the films directly to user's mobile phones using Bluetooth from inside the Watershed building. We were quoted approximately £2000 to enable this from a single access point for twenty four days. The 'transmitter module' would be shipped to us, we would install it securely in the building and supply it with an Internet connection. Set-up and Configuration would be done remotely. There wasn't a budget for this and we thought that Bluetooth broadcasting was a technology that would be useful for us to repeat so we allowed ourselves a few days to write the software.
We decided to write a desktop application (called Beamer). Strange when a daemon would perhaps have been a better choice but we hope one day to make the application an easy to use broadcasting application for any user with playlists and other features. We built a Cocoa application using Core Data to store discovered device lists and preferences. Bluetooth connectivity was handled using C functions and Objective-C methods in the IOBluetooth framework. The application was deployed on a Mac Mini (Core 2 Duo) running 10.4.10 for December 1st 2007.
Each day, a different film from Electric December is broadcast to mobile phone users in the foyer and Café Bar.
Statistics
The statistics listed are for the period December 1st - 24th, 2007.
Total number of devices detected: 2540. Although the Mac Mini was surrounded on most sides by copious amounts of tin foil to make the radio signal as directional as possible it often registered mobile phones from people walking along the quayside below or using the Chicago Rock bar. Beamer was only looking for phones, PDAs and similar mobile devices and this number does not include laptop and desktop computers.
Device names not registered: 972. Some users moved so quickly through the space that they were out of range before Beamer had a chance to ask the device for its name. For the first half of December the films were broadcast from Watershed's foyer, above the Box Office, but we noticed that apart from the periods when visitors queue for the cinemas in the evenings, a space with a large turnover of transient users is not ideal location. For the second half of the transmission period the Mac Mini was located in the Café Bar, below the spirits' rack, and this increased the number of names retrieved and connections attempted.
Number of users refusing a film: 104. Beamer would attempt to send the film to a user' mobile twice. If a device rejected the offer of a film twice it was never asked again for the duration of Electric December.
Number of films successfully transferred: 65. The films were transferred to 57 different devices so a small number of users, mostly staff, received more than one film.
Number of devices connection attempted: 1077. Beamer attempted to connect to roughly two thirds of the mobile devices that stayed around long enough to get the display name but only managed a connection in less than 20% of cases. There are many possible reasons for this and some in this broadcast include:
- A connection was initiated but the owner frequently failed to notice the notification on the screen.
- The mobile device did not support the transfer protocols needed.
- Each film was around 1MB and many devices do not have enough storage to hold files of this size.
Daily Distribution
The number of films transferred roughly parallels the pattern shown by the Electric December web site. The largest numbers are recorded when interest in the project is high at the start of the month and gradually decreases over the month until just before Christmas when the project is forgotten.
In the early days of the deployment, kernel panics were frequent and and Beamer only managed to run for a number of hours at a time. Days two and five were days when the application was only running for a small number of hours. From the graph it can be clearly see that, unfortunately, some days Beamer didn't run at all. For the first part of the deployment, a kernel panic had locked up the machine and it needed to be restarted. Later in the deployment, the mains electrical supply was not turned on and the Mac Mini failed to start.
Future Bluetooth Applications
The number of films transferred, although not huge, is a promising start. Downtime was approximately 25% so the total number of films distributed could be improved upon easily. As well as future short film distribution, Bluetooth could also be used to distribute other information to users of the Watershed such as contact or screening information. Having written that, I'm not convinced that broadcasting, unannounced content out to mobile phones will ever be that successful on a large scale. I'm hoping at some point in the near future, to produce a 'kiosk' type viewer with user initiated wireless transfers to mobile phones and devices. Having the user send a film to their own device is far less intrusive and perhaps would be used widely.
Multi-Channel Audio
Delivering forty channel audio using QuickTime APIs to adjust movie files.
A little while ago, Oliver (Watershed's ICT Co-ordinator) , asked me to write a small command line tool to set the audio output channels of a QuickTime movie. Oliver was writing software for Dream Director, a project that plays audio to people sleeping in pods in response to rapid eye movement.
A Mac mini plays back the audio to up to twenty pods (containing sleeping people) through a collection of M-Audio Firewire410 boxes. As the audio-out hardware units have been aggregated into a single virtual device with forty available channels, it was just a case of playing back a stereo file through a selected pair of channels.
QuickTime movies will save the audio channel mapping inside the file, so the requirement was to build a tool that would set the selected channels in a movie and save the file to disk. The source listing is for a Cocoa command-line Tool, using QTKit, to open an audio file, set the track mapping and save as a QuickTime movie.
QuickTime now uses Core Audio to handle the audio channel mapping and I thought this may be of some use to people. The partial listing below shows the code needed to map audio channels using QuickTime and a link to the source file of the tool is below the listing. Sorry about the wrapped source listing.
Movie qtMovie = [movie quickTimeMovie];Track audioTrack = GetMovieIndTrack(qtMovie,1);AudioChannelLayout* trackChannelLayout = NULL;OSStatus err = noErr;UInt32 trackChannelLayoutSize;// Allocate a layout of the required sizetrackChannelLayoutSize = fieldOffset(AudioChannelLayout, mChannelDescriptions[2]);trackChannelLayout = (AudioChannelLayout*)calloc(1, trackChannelLayoutSize);trackChannelLayout->mChannelLayoutTag = kAudioChannelLayoutTag_UseChannelDescriptions;trackChannelLayout->mNumberChannelDescriptions = 2;// Adjust the channel Assignment so that for an index we get a pair of channel// allocations. The index starts at 1// index channelA channelB// -----------------------------// 1 discreet0 discreet1// 2 discreet2 discreet3// 3 discreet4 discreet5// 4 discreet6 discreet7// ... and so onchannelAssignment = (channelAssignment-1)*2;#warning This will break if Apple change the CoreAudio's Channel Layout internalstrackChannelLayout->mChannelDescriptions[0].mChannelLabel = (1L<<16) | channelAssignment;trackChannelLayout->mChannelDescriptions[1].mChannelLabel = (1L<<16) | (channelAssignment + 1);// Set the track layouterr = QTSetTrackProperty(audioTrack, kQTPropertyClass_Audio, kQTAudioPropertyID_ChannelLayout, trackChannelLayoutSize, trackChannelLayout);if (err != noErr) {NSLog(@"**Error** QuickTime SetPropertyError: %i", err);return 1;}
Download the full source code.
Do people search?
In the era of viral content, RSS feeds and social bookmarking do people search any more?
Information and new content is so pervasive and is being created at an ever-increasing rate do peopIe have any time to search? In an environment where 'newer' is often seen as 'better' Users are enjoying the relative luxury of having targeted content, that they have chosen, delivered to their desktops through technologies such as RSS news feeds and podcasts.
Social bookmarking and selection sites present third party content arranged in a natural, almost evolutionary, way. Popular content bubbles up to the top of the pile and by being there is presented more often. This works in a similar way to the way your favourite mug is always at the front of the cub-hoard or shirt at the front of the wardrobe. Should content be displayed using a simple ranking mechanism to control positioning?
How many links to short pieces of video content are followed from email recommendations from trusted sources (although with the amount of money spent on 'viral marketing' through email and actors being paid to strike up conversations with strangers on the streets and trains about products these become less trusted)? The content has been selected and is in your in-box waiting for you to make the decision to view it.
Looking at the search statistics for some of Watershed previous and current projects would suggest that search is not a high priority for must users:
- 0.34% of requests were search requests for Electric December during December 2005
- 0.60% of requests to watershed.co.uk are search requests
- 0.21% of requests to dShed/Digitised are search requests
Pre-set searches, or showcases, may be useful to users and to us to promote old content from the archive alongside newer content, such as "recently added short films" or "gay and lesbian animation". These smart searches could be initiated by administrative staff or users of the site.
Does an archive have the values it once had? An archive's value may lie simply in it's URI: a location for trusted new content.
Lots of the structure to hold and display content has been over-specified for past projects and we want to make sure functionality will be used before devoting engineering resources to it.
dShed Search
As part of the redevelopment of dShed we are looking at search techniques for the dShed site and now wondering what user features it should contain.
For content that has a pedigree a simple search text field will do the job. The iTunes Music Store has approximately three and a half million items available and locating an item is trouble free. Similarly, selecting products to purchase using Amazon's single text field isn't something that causes lots of issues.
Will this approach work for content that is unknown? Using a text field that searches enough attributes and anticipates the users intentions would be sufficient for most situations. An example/ prototype for a simple search is illustrated at www.dshed.net/benjamin/. This is not an interface demonstration, is not fully implemented and only works in recent versions of Safari and Firefox. This searches for Creations based on the following attributes:
- title
- series.title
- series.project.title
- creator.title
Using these four attributes users can find a wide variety of content:
- "6 g" will find the short film 6 Goats from Depict
- "architecture" will get the series of films made for Architecture Week as part of 90 Second Challenge
- "90 sec'' will get the content from 90 Second Challenge
- "colmar'' will find the content made by Ralph Juergen Colmar
- "bridge'' will find lots of photographs of bridges
Increasing the number of attributes, from the four listed above, would allow the user to find items based on abstract properties or human interpreted descriptions but will also return more false positives. Performance will also degrades as the number of attributes increases. Current metadata is sufficient to specify Creations with a fine granularity and also synthesise collections of creative content. In fact, we are looking to reduce the metadata overhead associated with each Creation.
At some point, as the number of attributes increases an attribute specific advanced search (such as Digitised’s Advanced Search) will return higher dividends to users.
The search mechanism is currently an engineering project to test performance and possible optimisations so the results from the demo simple search are simply returned in alphanumerical order and there is no ranking. One obvious performance optimisation would be to track searches progressively.
Currently, as a user types another character, a new search request is generated. Imagine the user is looking for the film 6 Goats. The user begins by typing "6" and the application searches the dShed archive. Next the user adds a space and the application searches the archive using the terms "6 ". Next the user adds a 'g' and the application searches the entire archive using the terms "6 g". At each stage, a new search is of the entire archive is initiated. Using some form of session identifier, we can track the progress of individual searches and, where appropriate, just search the results of the user's previous search.
Maybe search should be about trying to guess what the user wants rather than the act of simply matching search terms? If no results are found maybe we can try searching on a further set of different attributes or else try to return something similar or useful. The lowest point in a browsing session is when no results are returned from a search; this says 'this site has nothing for me and I am in the wrong place'.
MPEG4 on dShed
For the last eight years Watershed has always distributed video over the Web using QuickTime .mov files. The last time we explored encoding and distribution standards was during the research stage of the Digitised project in 2001. As we start to think about dShed and the implications of a digital archive it's time to look at how we produce, and our users consume, video.
As all of the video content becomes part of the dShed archive we need to think about what is best for the future users of the archive not just the users of dShed this week.
The move away from Sorenson Video codec in QuickTime could be a painful process. Using MPEG4 pt10 files in Electric December 2005 meant that almost all of Watershed's staff were unable to view the video content. The public viewing computers around the building all required upgrades.
Apple have set the hardware and OS bar quite high for QuickTime 7, especially (and ironically) for Macintosh users. Many Windows users are reticent about upgrading to QuickTime 7 because the most prominently displayed installer installs iTunes as an 'added extra'. iTunes will probably become Apple's default media player in the future replicating the UI mistakes Real made almost 10 years ago.
The transition to MPEG4 will be a gradual process. Currently some QuickTime files use h264 and AAC encoding. Even when the files become fully compliant we will still push the files through the QuickTime plug-in to maintain a consistently good user experience (unless they don't have QuickTime installed).
Using h264 and AAC gives much smaller file sizes for the equivalent quality. This saving can be substantial with thousands of visitors viewing large video files. We get reduced bandwidth costs and the users spend less time downloading and more time viewing. Other advantages include local colour and gamma correction. Some people compress a different version with colour and gamma settings for each platform; we didn't. Previously, the gamma was set somewhere between that of a Macintosh and a Windows PC, with no user getting the best experience.
We may lose some content viewers by requiring QuickTime 7 to view the video in the browser but we will gain many more users by leveraging a common, standard media format that is supported by low power consumption, hardware decoders in a variety of portable devices. The iPod and PSP currently account for most of these, but their share will diminish as more and more mobile phones get the decoders.
New distribution methods, such as video podcasts, allow us to broadcast further to an audience that has 'opted in' to view specific content. After we added a 90 Second Challenge video podcast to the iTunes Music Store, even before video iPods were released, the feed accounted for 62% of all traffic to dShed.
In the short-term we may loose up to 30% of current potential viewers but will gain more than a 300% increase through new deployment opportunities.
The podcast distribution format appears almost too good to be true. It took half a day to add the podcast to the web application. The podcast is marketed by Apple (using iTMS) and other directory sites to a very large number of users at no cost or effort on our part. It is quite wondrous when comparing the time and money spent developing large content umbrella and directory sites. There may even be a situation where we don't need a web-site - just a podcast.
iTunes Video Podcast
We've had a video podcast of recent additions to the 90 Second Challenge for some time now. In fact the podcast has been running since before Apple released the video iPod linked from the 90 Second Challenge Web site.
It's only since Apple started promoting video podcasts through the iTunes Music Store that subscribers have increased. Since the 90SC podcast was highlighted in the iTMS, iTunes accounts for 62% for all requests to the dshed.net site. From all the content available in dShed, 10 microfilms account for a large proportion of the traffic.
Of course we don't know if the films are actually being watched but it is definitely a distribution method we are interested in taking advantage of in the future.