Contentment

Brown paper packages tied up with stringsI was having a discussion earlier on IRC about the role of the N900’s App Manager. The question I’m raising is: is it legitimate to package non-programs which can be already downloaded in another way?

Here’s an example.  A film which is DFSG-free such as Sita Sings the Blues could be packaged as an app.  The package would install the .mp4 of the film, which would then appear in Media Player, but perhaps would also have an icon in the launcher.  (Of course people can already find Sita on the web and watch or download it there, giving the same effect, but then they might be more likely to find it in the app launcher.)

Far-fetched?  Not really; there are already iPhone apps which contain only a book, and there are existing Debian packages which only install free HTML and text content.

Since films are essentially documents which can be opened by Media Player, the question can be generalised: Should documents be packaged, or only apps? When someone ports Frotz to the N900, should it have its own separate download manager for Z-machine games inside it as the iPhone port does, or should each game become available in the App Manager as a separate package as used to be done on Debian?

And then there are radio stations such as Soma FM which have iPhone apps to let you listen to them.  Now of course you can already do this in the N900’s media player, so would it be worthwhile for them to package a specific N900 app which connected to their streams?  Or to make a package which only populated the media player with a list of them?

But just because people do something with the iPhone it’s not necessarily a good idea:

  • media packages should probably install into /home/user/MyDocs or /media/mmc*, but the conventional place for large files in app packages is /opt, which would fill up quite quickly with a few Sita-sized films
  • each package gets to run scripts as root, and this may have more security considerations than people are comfortable with just to watch a film
  • people expect app stores to contain apps (don’t they?)

I think an alternative route would be to have one standard application which could maintain a browsable list of Free content, and which could download it for you as appropriate.  Maybe it could be extensible to act as a download manager for Free content for the emulators and so on, as well as just films and text.  What do you think of all this?

Photo © Caro’s Lines, cc-by-nc-sa.

8 Responses to “Contentment”

  1. HoellP says:

    I totally like the idea.
    I really think mediacontent should be clearly seperated from applications and personally i wouldn’t even touch those packages. But maybe i’d get the idea to look for it.

    I think it’s hard enough to find open content, an easy way to get an overview would be great to move it into the spotlight.

    In more practical terms, one could probably write a jamendoplugin for the musicplayer, a flickr/deviantart CC search for the pics app and port miro…

    I really like that you brought this idea up, sounds like something awesome.

  2. qhartman says:

    I’d be wary of packaging media up in the app manager for the same reasons you bring up. If it were to be done, I would suggest that it be given a category of its own like “content”, “media”, or the like. As for games that run in emulators, I can see the argument for treating them as “content” from a technical perspective, but I’d wager that the vast majority of users would more closely equate a game in this context to a program than a media file. The frotz method on the iPhone makes sense because of how their app store is built, but on the n900 we already have a well understood way to catalog, search, and download items (both in the app manager and the browser…). Re-creating that feature inside the application seems like wasted effort.

    As far as the “conventions” you mentioned, I’d suggest that in this case, any existing conventions be ignored and new convention for this this case be created to get around the technical limitations you mention.

    Your last suggestion though, the stand-alone application that maintains free content, is closer to the ideal. I would suggest that the application you mention be a website rather than an app. That gives it much enhanced usability (I can browse from my pc if I want, and perhaps consume the content there) and would seemingly make development and maintenance much simpler. Of course this would make the infrastructure required to make it go likely larger and more complex, so it’s a solution with trade-offs.

  3. Walther says:

    A content manager would be an excellent idea. I vote against using (just) a webserver, because it would be nice if my local content manager would now where to store it on my N900 (or pc) and what media indexes or playlists to update. Your browser usually doesn’t know this.

  4. AchipA says:

    The problem of putting content into MyDocs is that MyDocs will not necessarily be visible when that content is (un)installed. For example, what happens if someone tries to (un)install an app while connected via USB (and thus MyDocs is not mounted) ?

  5. I dislike the idea of packaging non-executable content as “applications”, whether for the N900 or Debian or whatever. Very little content requires any special setup when “installed”. They just require the file or files to be put in some suitable locations, and the suitability is primarily dictated by available space.

    Requiring any special packaging for content also drastically reduces the amount of (easily) available content.

    As a user I’d like to have a solution that makes it easy to, say, download an e-book that I stumble upon when browsing the net or reading blogs or identi.ca or wherever. Ideally, I’ll just click on the link in the browser and it gets put in the right place, and is then immediately available in the e-book reader.

    Ditto for all other kinds of content, obviously.

    That much is easy achieve. I would further like a solution that makes it easy to see where the content came from (so I can go back for sequels), and makes it easy to remove stuff I don’t want, etc. A “content manager” in parallel to an “app manager”.

    It’d require a bit of support from browsers and other tools for downloading stuff, but not too much.

  6. Hartti says:

    What is your take on desktop background image sets? They are content, but need proper configuration (.desktop file in a proper place with proper information on file locations) which can be achieved with a deb package easier than with manual “install”.

    If I read your correctly, you do not have anything against packaging themes, right?

  7. @Hartti:

    I have nothing particularly against packaging *anything*; I’m just trying to decide whether there’s a line and, if there is, where it should be drawn. I agree that themes are probably on the app installer side of it.

  8. pwnguin says:

    How about both? The official app manager only lists packages in category user/*, so you could package up data with a different category, store it in a separate repo and write a custom browser / installer that restricts itself to your new category. Or, if the App Manager were modified to allow it to be started with specific category scopes, that would also work. Then you could package themes, backgrounds, other media and zgames without necessarily cluttering anything.

    On the other hand, you should consider which advantages of packaging are suitable for the domain:
    * Do you regularly update your media collection with new versions? For technical ebooks I could perhaps see an advantage.
    * Do you want people to easily remove collections? This might be useful for the default media provided, to remove / replace the Getting Started video and trailers for movies no longer in theaters.
    * Do you want people to redownload the entire thing on upgrades? Currently apt-get doesn’t provide any binary diff to speed things up. There’s motions to fix this, but none in place yet.

    Finally, I’d describe the Soma.FM thing as a configuration package. We don’t generally do modular configuration packages, because there’s such a broad range of possible configurations.