Re: [9fans] acme mail "feature"

Re: [9fans] acme mail "feature"

[Caerwyn B Jones]

> I once saw a cgi that implemented recursive calls to a function by
invoking the
> cgi (itself) via an http request for the URL corresponding to it.

I implemented a fileserver that opened/read/write files that it was serving
itself
using the system calls.
I suppose this is folly. But is it called recursion?

-Caerwyn

Re: [9fans] acme mail "feature"

[Russ Cox]

> I implemented a fileserver that opened/read/write files that it was serving
> itself
> using the system calls.
> I suppose this is folly. But is it called recursion?

It's called deadlock unless you're really careful,
which I guess you were.

Russ

Re: [9fans] acme mail "feature"

[Caerwyn B Jones]

> > I suppose this is folly. But is it called recursion?
>
> It's called deadlock unless you're really careful,
> which I guess you were.

Right. So I'm indirectly calling the same function
but always in a different thread.

[9fans] acme mail "feature"

[Sam]

Does anyone find it useful that acme mail highlights the
incoming mail, deselecting whatever was previously
highlighted?

I'll highlight half a screen full of mail and as I'm
mousing up to Delmesg -- or even worse, right before I
click it -- new mail comes in and undoes me.

It's happened enough times that I'm pretty sick of
this "feature."  I'll hunt it down and squash it
if others agree.

Sam

Re: [9fans] acme mail "feature"

[rog]

> Does anyone find it useful that acme mail highlights the
> incoming mail, deselecting whatever was previously
> highlighted?
[...]
> It's happened enough times that I'm pretty sick of
> this "feature."  I'll hunt it down and squash it
> if others agree.

it's probably an automatic consequence of inserting new text.  if you
want to avoid it, you'll have to add code to set the selection back to
what it was, but i'm not sure how easy that'll be when the user might
be changing the text too.

personally, this hasn't bitten me much.  what i would like though is
some way of tagging messages.  it'd be nice to know which messages i
haven't read, for example (i've missed important emails in the past
when receiving lots of mail), and i'd like to be able to tag mail
items as "needs further attention"/"must reply".

but the thing that most needs fixing (for my usage pattern anyway) is
the way that upas/fs reads the entire mailbox into RAM. i get around
this by periodically archiving my mailbox, deleting all but the most
recent 6 month's worth of messages, but i'd prefer not to do this.

all that said, i think the combination of acme mail and upas/fs
is excellent, and i wouldn't use anything else!

Re: [9fans] acme mail "feature"

[andrey mirtchovski]

> personally, this hasn't bitten me much.  what i would like though is
> some way of tagging messages.  it'd be nice to know which messages i

How hard would it be to add a new command "Read" or "MarkRead" similar to
"Delmesg" that just marks the mail as (read)-? It doesn't have to be
automatic on right-click, just another way to close the window -- instead of
hitting 'Del', middle-click 'Read' (or 'Readed' to avoid confusion :)...

Naturally one would like to have read messages tagged when acme starts too.

I may take a look later today, but I readily admit I know little to nothing
about acme programming and Mail :)

andrey

Re: [9fans] acme mail "feature"

[rog]

> How hard would it be to add a new command "Read" or "MarkRead" similar to
> "Delmesg" that just marks the mail as (read)-?

this facility would need to be added to upas/fs - that would probably
be the main difficulty.  of course, you'd have to change the mailbox
interface too, and work out where you were going to store the extra
data, and make sure that it couldn't become inconsistent.  and given
that upas/fs can look at different kinds of mailbox, it might not be
possible for some mailbox kinds (e.g.  pop3).

basically it's not trivial, which is probably why no-one has put in
the necessary comprehension and implementation effort, given that most
people have higher priority items on their lists...

Re: [9fans] acme mail "feature"

[Fco. J. Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 274 bytes --]

It's the user interface that I cannot imagine.
Otherwise, placing a `read' mark in the mail should not be hard.
Either a new header or just in-memory while in upas/fs.
But, how to handle it properly in /acme/mail/Mail ?
Perhaps showing read messages after non-read ones?

[-- Attachment #2: Type: message/rfc822, Size: 2782 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] acme mail "feature"
Date: Fri, 1 Oct 2004 15:45:55 +0100
Message-ID: <dcce99bb8d9b58c9adecdcff92ac9d17@vitanuova.com>

> How hard would it be to add a new command "Read" or "MarkRead" similar to
> "Delmesg" that just marks the mail as (read)-?

this facility would need to be added to upas/fs - that would probably
be the main difficulty.  of course, you'd have to change the mailbox
interface too, and work out where you were going to store the extra
data, and make sure that it couldn't become inconsistent.  and given
that upas/fs can look at different kinds of mailbox, it might not be
possible for some mailbox kinds (e.g.  pop3).

basically it's not trivial, which is probably why no-one has put in
the necessary comprehension and implementation effort, given that most
people have higher priority items on their lists...

Re: [9fans] acme mail "feature"

[Axel Belinfante]

> Otherwise, placing a `read' mark in the mail should not be hard.
> Either a new header

isn't that what mail  (or Mail or so) on unix (at least solaris) does?

> or just in-memory while in upas/fs.

Getting off-thread:
would it be possible to plan9port upas/fs and acme mail?
(guess I should not ask but try, but maybe someone already has an
 idea whether there would be stumbling blocks, and if so, where)

Axel.

Re: [9fans] acme mail "feature"

[Fco. J. Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 124 bytes --]

I think so.
I think the unix mail tool I used would place an
X-something: header to stopre it's flags (read,replied,etc.).

[-- Attachment #2: Type: message/rfc822, Size: 3932 bytes --]

From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] acme mail "feature"
Date: Fri, 01 Oct 2004 16:51:01 +0200
Message-ID: <200410011451.i91Ep1U13835@zamenhof.cs.utwente.nl>

> Otherwise, placing a `read' mark in the mail should not be hard.
> Either a new header

isn't that what mail  (or Mail or so) on unix (at least solaris) does?

> or just in-memory while in upas/fs.

Getting off-thread:
would it be possible to plan9port upas/fs and acme mail?
(guess I should not ask but try, but maybe someone already has an
 idea whether there would be stumbling blocks, and if so, where)

Axel.

Re: [9fans] acme mail "feature"

[boyd, rounin]

> I think so.
> I think the unix mail tool I used would place an
> X-something: header to stopre it's flags (read,replied,etc.).

it does and it's a dreadful idea because it modifies the original message.

any such tagging should be OOB.

Re: [9fans] acme mail "feature"

[C H Forsyth]

>>the problem is that mail is now large as various dingbats have
>>decided to use it for file transfer via MIME.  this problem and

i knew someone who copied files from one directory to another
on the same (unix!) system by sending them to himself as email then saving them.

Re: [9fans] acme mail "feature"

[Skip Tavakkolian]

I once saw a cgi that implemented recursive calls to a function by invoking the 
cgi (itself) via an http request for the URL corresponding to it.

Re: [9fans] acme mail "feature"

[George Michaelson]

isn't that more in the nature of a co-routine than a recursive function?
after all, its across a network boundary..

-George

Re: [9fans] acme mail "feature"

[andrey mirtchovski]

no, it's grid computing -- it's clearly accessing remote web services :)

Re: [9fans] acme mail "feature"

[rog]

> But, how to handle it properly in /acme/mail/Mail ?
> Perhaps showing read messages after non-read ones?

for my purposes, just adding a tag in square brackets, like [deleted]
and [replied] would be fine.  searching's easy, and i've been known to
use Edit on the acme representation of the mailbox, such as

	Edit ,x/^[0-9].*\n(	.*\n)?/g/\[9fans\]/d

to avoid showing any 9fans messages, for example.

> Either a new header or just in-memory while in upas/fs.

for me, it would be fairly pointless if it wasn't persistent.
i wish [replied] was persistent too.

Re: [9fans] acme mail "feature"

[Richard Miller]

> 	Edit ,x/^[0-9].*\n(	.*\n)?/g/\[9fans\]/d

I just tried this in my /mail/fs/mbox/ window and got an interesting
error message:

elogapply: can't happen 2214 2324 769

-- Richard

Re: [9fans] acme mail "feature"

[Russ Cox]

> How hard would it be to add a new command "Read" or "MarkRead" similar to
> "Delmesg" that just marks the mail as (read)-? It doesn't have to be
> automatic on right-click, just another way to close the window -- instead of
> hitting 'Del', middle-click 'Read' (or 'Readed' to avoid confusion :)...
> 
> Naturally one would like to have read messages tagged when acme starts too.
> 
> I may take a look later today, but I readily admit I know little to nothing
> about acme programming and Mail :)

the annoying part is maintaining the list of read messages.
actually adding the command is easy.

marking something as read isn't so interesting unless it
appears differently than unread messages - like not at all.
if you're going to add a read bit, i'd like to see just the unread
messages somehow, perhaps even by default.

russ

Re: [9fans] acme mail "feature"

[Brantley Coile]

> but the thing that most needs fixing (for my usage pattern anyway) is
> the way that upas/fs reads the entire mailbox into RAM. i get around
> this by periodically archiving my mailbox, deleting all but the most
> recent 6 month's worth of messages, but i'd prefer not to do this.

I agree.  I have a user who accesses his mail box from pop and keeps
all the mail on the server.  He has run up pretty large mail boxes in the past.

> 
> all that said, i think the combination of acme mail and upas/fs
> is excellent, and i wouldn't use anything else!

Here, here!!

Re: [9fans] acme mail "feature"

[Axel Belinfante]

> > but the thing that most needs fixing (for my usage pattern anyway) is
> > the way that upas/fs reads the entire mailbox into RAM. i get around
> > this by periodically archiving my mailbox, deleting all but the most
> > recent 6 month's worth of messages, but i'd prefer not to do this.
> 
> I agree.  I have a user who accesses his mail box from pop and keeps
> all the mail on the server.  He has run up pretty large mail boxes
> in the past.

trying to read a cd-size archive of a single mail folder can be fun too.

Axel.

Re: [9fans] acme mail "feature"

[Fco. J. Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

I think upas/fs wont read messages before it's needed when
using imap. At least, I remember changing it do work that way
(Hmm, I think it required also a change in acme Mail, but I'm
not sure).

It's loooong since I used that feature for the last time, so
I'm not sure about what's upas/fs doing.

Also, IIRC, you have to read all the messages if you're using
pop instead of imap.

Once the message is here, reading it into ram is not a serious
problem unless you keep many many messages or very big ones.

[-- Attachment #2: Type: message/rfc822, Size: 2645 bytes --]

From: Brantley Coile <brantley@coraid.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] acme mail "feature"
Date: Fri, 1 Oct 2004 10:49:02 -0400
Message-ID: <14096ba5db5eb3013ad32ee1a3efa237@coraid.com>

> but the thing that most needs fixing (for my usage pattern anyway) is
> the way that upas/fs reads the entire mailbox into RAM. i get around
> this by periodically archiving my mailbox, deleting all but the most
> recent 6 month's worth of messages, but i'd prefer not to do this.

I agree.  I have a user who accesses his mail box from pop and keeps
all the mail on the server.  He has run up pretty large mail boxes in the past.

> 
> all that said, i think the combination of acme mail and upas/fs
> is excellent, and i wouldn't use anything else!

Here, here!!

Re: [9fans] acme mail "feature"

[Brantley Coile]

> Once the message is here, reading it into ram is not a serious
> problem unless you keep many many messages or very big ones.

Which is the problem with pop users on pc's that leave the
mail in the mail box.

Re: [9fans] acme mail "feature"

[Fco. J. Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 73 bytes --]

Why not just switch to imap?
Isn't pop the problem (instead of upas/fs)?

[-- Attachment #2: Type: message/rfc822, Size: 2286 bytes --]

From: Brantley Coile <brantley@coraid.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] acme mail "feature"
Date: Fri, 1 Oct 2004 10:59:18 -0400
Message-ID: <323a591e5da8ffec8dee52874d2104c1@coraid.com>

> Once the message is here, reading it into ram is not a serious
> problem unless you keep many many messages or very big ones.

Which is the problem with pop users on pc's that leave the
mail in the mail box.

Re: [9fans] acme mail "feature"

[rog]

> Once the message is here, reading it into ram is not a serious
> problem unless you keep many many messages or very big ones.

i like to keep a record of all the significant mail i've received.
it helps my faulty memory.

that means that i do keep lots of messages around.
du /mail/box/rog gives 136MB and my current
mailbox is 31MB, which leads to a memory usage for
upas/fs of about 54MB - quite a lot of memory to expend
on stuff that i mostly don't look at (although i grep through
the sender, subject and date quite often).

the real problem is attachments - someone will send me
a 20MB email containing some important text and a load
of pictures. i'd prefer not to have to delete such emails (or
segregate them into a different mailbox).

russ:
> marking something as read isn't so interesting unless it
> appears differently than unread messages - like not at all.
> if you're going to add a read bit, i'd like to see just the unread
> messages somehow, perhaps even by default.

this could just be one possible view. rather than having several
mailboxes, one could have several different views onto
the same mailbox, each with its own selection criteria.

Re: [9fans] acme mail "feature"

[boyd, rounin]

> Once the message is here, reading it into ram is not a serious
> problem unless you keep many many messages or very big ones.

the problem is that mail is now large as various dingbats have
decided to use it for file transfer via MIME.  this problem and
just the sheer quantity of mail means that any user agent should
be able to scale to cope with either case.

i don't see an F in SMTP.