[9fans] faces and the plumb messages received by cpu connections

[9fans] faces and the plumb messages received by cpu connections

[Gabriel Díaz]

Hello

I cpu'ed to a host A, and cpu forwarded a plumb message about a new mail, 
so faces displays it, but it has no access to it as that upas/fs is in other
namespace.

If I click on the message, faces tries to open the email with the number
from the 
Plumb message. If you have that index number on your local inbox you will
see the
Corresponding email.

What do you think about adding a field to the message with the name of the
machine
so faces can at least give you a pointer to where the message comes from?

Is that totally silly, am I missing difficulties hidden somewhere?

Thanks 

Gabi

Re: [9fans] faces and the plumb messages received by cpu connections

[Steve Simon]

I would suggest a better solution would be to start the local upas/fs
watching the two different mailboxes - I haven't tried this for a long time
but it should work (bitrot not withstanding).

in your profile:

	plumber
	9fs remote
	upas/fs -n		# do not open /mail/box/$user/mbox
	echo open /mail/box/$user/mbox loc > /mail/fs/ctl
	echo open /remote/mail/box/$user/mbox rem > /mail/fs/ctl
	rio

There may still be some assumptions in the plumber or upas/fs
about the name of the mailbox to watch / plumb, however that
seems like the proper place for a fix (IMHO).

-Steve

Re: [9fans] faces and the plumb messages received by cpu connections

[erik quanstrom]

i use two mailboxes at work -- one local and one imap.  this 
requires some changes to nedmail as ned assumed that
any named mbox needed to be reopened.

my copy of nedmail is in /n/sources/contrib/quanstro/nedmail.c.
if this is helpful, let me know and i'll clean it up for submission.

- erik

On Fri Mar 16 08:40:21 EDT 2007, steve@quintile.net wrote:
> I would suggest a better solution would be to start the local upas/fs
> watching the two different mailboxes - I haven't tried this for a long time
> but it should work (bitrot not withstanding).
> 
> in your profile:
> 
> 	plumber
> 	9fs remote
> 	upas/fs -n		# do not open /mail/box/$user/mbox
> 	echo open /mail/box/$user/mbox loc > /mail/fs/ctl
> 	echo open /remote/mail/box/$user/mbox rem > /mail/fs/ctl
> 	rio
> 
> There may still be some assumptions in the plumber or upas/fs
> about the name of the mailbox to watch / plumb, however that
> seems like the proper place for a fix (IMHO).

Re: [9fans] faces and the plumb messages received by cpu connections

[Russ Cox]

Plumber is working fine.  You simply asked it to connect
two programs inappropriately -- an upas/nedmail running
in one name space with an upas/fs running in a different
name space.

If, on the other hand, you were also running acme Mail
in the cpu window, then everything would have worked out
fine, even though plumber and faces are on different
machines from upas/fs and Mail.

Embedding machine names in messages attacks the
generality and power of the system.

Plan 9 relies heavily on its conventions.  If you break the
conventions, sometimes the system doesn't work as well
(bind /net/tcp /proc && ps).

But being able to break the conventions is important and
powerful, because if you break them just a little, sometimes
the system works even better (import helix /proc && acid 123;
sshnet; snapfs; bind /mnt/term/net/tcp /net/tcp && ssh; etc.).

Russ

Re: [9fans] faces and the plumb messages received by cpu connections

[Gabriel Diaz]

hello

thanks all for the comments.

i suppose an rc script is enough to add
the cpu'ed mailbox to the local one without
having a pre-configured script, to get faces and
upasfs working with cpued hosts.

gabi


On 3/16/07, Russ Cox <rsc@swtch.com> wrote:
> Plumber is working fine.  You simply asked it to connect
> two programs inappropriately -- an upas/nedmail running
> in one name space with an upas/fs running in a different
> name space.
>
> If, on the other hand, you were also running acme Mail
> in the cpu window, then everything would have worked out
> fine, even though plumber and faces are on different
> machines from upas/fs and Mail.
>
> Embedding machine names in messages attacks the
> generality and power of the system.
>
> Plan 9 relies heavily on its conventions.  If you break the
> conventions, sometimes the system doesn't work as well
> (bind /net/tcp /proc && ps).
>
> But being able to break the conventions is important and
> powerful, because if you break them just a little, sometimes
> the system works even better (import helix /proc && acid 123;
> sshnet; snapfs; bind /mnt/term/net/tcp /net/tcp && ssh; etc.).
>
> Russ
>