Hi, On Sat, Apr 17, 2010 at 10:54:37AM +0200, Patrik Olsson wrote: > On Fri, 2010-04-16 at 11:52 +0200, Carl Fredrik Hammar wrote: > > On Thu, Apr 15, 2010 at 10:47:49PM +0200, Patrik Olsson wrote: > > > 3. Is it possible to have one translator working on two nodes at > > > the same time (where the nodes have different meaning)? HPM > > > needs to build one target directory (node one), and then have > > > the interface directory where the user can control the manager > > > (node two). > > > > Yes, a translator can attach itself to multiple nodes, but if a translator > > takes an active role in attaching itself it cannot be set as a passive > > (start on demand) translator. > > > > Instead, you probably want some inferior translator that contacts a > > master translator. For instance, the interface directory could be a > > separate translator that sends commands to the target directory translator > > via some specialized interface. This could also allow the user to have > > several interface directories. > > > > I also had another alternative in mind. That the interface directory is > derived from the target directory. So if the target is / then the > interface could be part of that node as /hpm.
Yes, this would be a simple yet effective approach. > I really don't see the point of several interface directories as they > would be identical, and it would only complicate handling concurrent > editing. Besides, if users really want many interface directories, there > are symlinks. It mostly shows that this approach is naturally flexible. Indeed, there is no point if they are identical, but you bring up a use-case yourself further down. > > > 4. Is it possible for a translator to provide different views of > > > the node for different users? For example, could each user have > > > their own list of packages they want installed and the HPM > > > translator would use ref-counting to install packages with > > > ref-count > 0, and/or perhaps even make different packages > > > appear installed for different users? > > > > This is actually possible, as the translator knows the user of the > > client so it can grant or withhold access. But I suspect that using > > it to provide different services to different users would violate many > > assumptions made by clients. > > What are "clients" in this context? The processes using the translator. Though I guess also end-users could make such assumtions. > > I wouldn't object using this to provide something like `/dev/whoami' > > which would contain the UID of the reading process, but I don't think > > you should consider this possibility for HPM any further. Just go with > > different translators or nodes for different users. > > I think I'll do a mix. Only the interface directory would be different > for each user. This is also necessary so that users don't overwrite each > others changes if they are editing the installation list at around the > same time. If the user cannot install a package with the system HPM > (e.g. the package is experimental), they would use a private HPM > instance instead. But they should prefer the system HPM since it won't > use up their disk quota (and it will save disk space on the system as a > whole). But perhaps there is another way, so I'll think about it some > more. This problem would go away if you allow several interface directories, one per user. I do think that is the cleanest way to handle this: different nodes for different directories means there can be no confusion. However, I think it is best to post-pone discussing how several users would interact with HPM, and first implement system-wide only, then private HPMs that overshadows the system one, and then we can discuss some ability for regular users to make direct use of the system one. > Thanks for your help. No problem, glad I could help. Regards, Fredrik
