[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Many questions about translators

From: Carl Fredrik Hammar
Subject: Re: Many questions about translators
Date: Mon, 19 Apr 2010 15:16:48 +0200
User-agent: Mutt/1.5.20 (2009-06-14)


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]