ext Thiago Macieira <[email protected]> writes: > Em Terça-feira 07 Setembro 2010, às 12:20:36, Marius Vollmer escreveu: >> Think of two games that share a common engine: when buying any one of >> the games, you will implicitly buy the engine, too, and the store will >> give you permission to download both the game package as well as the >> engine package. Then when the game is installed, the engine is >> installed at the same time (invisibly to you). When you buy the second >> game later, you already [h]ave the engine. > > True, but that's more like the Store application being told to download more > than one package to complete the installation. It doesn't sound like > dependency management to me from the classical approach. > > The classic approach to dependency management is that the client side figures > out that it needs to download extra packages in order to satisfy the > dependencies of what it's trying to install. The case above is server-side > dependency management: the new package is pushed to the client.
Are you saying that with server side dependency management, the game package would not formally require the engine package, and we would rely on the Store to do the right thing? And if someone manages to shove the game package into the device without the engine somehow, we just let it fail mysteriously? Thus, I'd say it doesn't matter where you do the resolution, the packages still need to declare their requirements in the usual way. The question here is whether or not to allow a 3rd party package to require another 3rd party package at all. And this is indeed mostly a question for the Store (and the parts of it that run on the device), which is probably very vendor specific. Unless we make a canonical MeeGo Store, which I think we should, if only as a technology demonstration. >> If we also figure out how to present updates to the engine package to >> the user, then this should work, no? > > And that's a different issue. Some upgrades may be paid for, others free. And > only the Store app can do that, since it needs to log in first. We have the SSO component (Single-Sign-On) also in MeeGo, no? That's how we let apt-get log into the Ovi Store in Harmattan. > Per-user repositories would be nice, but probably produce a huge load > on the server. There is no such thing as a free lunch. If you want to have fine-grained access control, you will have to pay for it, one way or another. A repository can be implemented in a number of ways, as long as it supports the two basic operations: getting meta data for a given set of packages in it, and downloading packages. The meta data does not need to be protected, only the packages need to be, and could thus be provided in some way that scales well. It turns out, however, that even the meta data needs to be 'per-user'. Different users will see different versions of a given package. That sucks a bit and I don't see why that would be a good idea, but control freaks will be control freaks... :) _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
