I cant actually find much of a design document as such for the app store.
All i know it's a completely bespoke development. I'm just going to give a bit of a lower level overview of how I would put the whole system together if I were starting from scratch, using tools I already know and am comfortable with. This is not meant to offend any work already done on the store or suggest it should be replaced, it's just informative. A lot of these components have analogs already.
Package distribution
for background, I am a Drupal core developer (drupal.org) , and the company i work for (development seed) has actually been writing some package distribution tools for drupal recently.
We call them 'feature servers'. This is developed as a 'feature' itself, so you can easily add it to an existing Drupal site, but very often you just want this functionality on it's own.
So for instance our public code website is a feature server and hosts the feature server itself - http://code.developmentseed.org/singular/dashboard
and other packages too - http://code.developmentseed.org/featureserver/dashboard
The following is a public feature server - http://community.featureservers.org/
or one of the basic private feature servers - http://features.pingv.com/
You can also take a look at the (admittedly drupal centric) video showing how to use it - http://vimeo.com/5314580
Now the 'magic' part of the feature server isn't just the allowing you to upload releases and tag them and so forth, it's that it also generates RSS feeds of all the packages and releases.
These are currently in drupal.org's xml format, but this was a rather simple addon to the fserver project and can be modified to do anything.
So for each project you have a separate feed of updates, and the .pnd file would have a link to this feed, and notify you of new releases when you run it.
We also have backend code and integration which physically builds packages from our code repositories and publishes them online (like git hook scripts etc.)
Because of the feeds, it is possible to build a different application to manage store downloads if need be.
It's also pretty simple to 'accoutrify' the projects with things like reviews , and do tagging for them so you can sort them. A very simple fixed width theme
that is conditionally switched when using the app store application on the pandora would provide a clean and easy to develop user interface.
At some point we could integrate Ubercart (www.ubercart.org) , and give provisional download access to packages only to people who have paid..
The next part is more interesting and technical however ...
central login
We would need to install an identity store somewhere, that various things can connect to. So I would probably install LDAP, and on the drupal site , i would add the following : http://drupal.org/project/ldap_integration and http://drupal.org/project/ldap_provisioning
This would mean that creating an account on the website, creates the account on LDAP , and vice versa. During initialization of the pandora, or when using the web store
from the pandora for the first time, we would step the user through creating an account (which is optional of course). If they have an account we seed the details into the
backend jabber client that manages updates.
We're actually rather lucky in that we have a fairly flat organizational model. I've seen some crazy stuff needing to integrate jabber with large complex organizations.
xmpp - server
We would install an XMPP server, probably something like ejabberd, to use the data store of accounts we created on the web site. So your website login is your jabber login etc.
ejabberd is also interesting in that it seems to support some XEPs which allow for server side scripting, so you could potentially write some rather interesting interactions.
xmpp - client
There would be a small daemon on the pandora itself, using very little memory and only making a connection to the jabber server when it needs to, that would simply be
accessed through the library level only. IE: in the game or emulator you would have an api call that would say "current status". At first we might just use a text string,
but we can extend it further as the tinxl spec specifies.
We can then further decide whether we want to build our own roster management utility, but the included client (pidgin) will also work with the account details, so you already
have full chat and friend management, with the ability to share status with them.
The real benefits in this will only come as the user facing component integrating into the small backend jabber client becomes more evolved. We'd be doing things that don't
really have place in pidgin, but pidgin would obviously still be usable for chat.
