In message <[EMAIL PROTECTED]>, also sprach Ken
Hornstein:
>>> I don't think they're rich enough to
>>> emulate everything that annotations give you.
>>
>>Because you can't add multiple ones per message, or because they're of a
>>fixed length, or...?
>
>The IMAP specification treats them as a
>Maybe he's talking about the ability of the UW imapd to access the MH
>folders you have on the server? I've used it before (in 'pine' to
>access a folder "{SYSTEM_NAME}#mh/lists/foo", for instance) to do just
>that. These days, I would just ssh in to the box and use nmh
>directly.
Was that a f
> > (2) When away from your main system, you might want to be able to
> > use IMAP to access your nmh folders from a remote site.
>
> _This_ would require a special IMAP server; I'm not sure one like
> this exists, and would be a lot of work. The IMAP model, for good
> or bad, is you alwa
>> I don't think they're rich enough to
>> emulate everything that annotations give you.
>
>Because you can't add multiple ones per message, or because they're of a
>fixed length, or...?
The IMAP specification treats them as a fairly scarce resource.
I haven't done a survey, but IMAP servers ar
Ken Hornstein <[EMAIL PROTECTED]> writes:
> >Well, anno might be implementable via the IMAP "tags" facility, no?
>
> Are you thinking about "flags"?
Yeah, sorry -- I'm just picking up the terminology from this discussion.
> I don't think they're rich enough to
> emulate everything that annot
>If we really wanted to use IMAP, we wouldn't be using 'nmh'.
You're not always given a choice, you know. What if company-wide
message boards are only available via your IMAP server?
>I can see two possible roles for IMAP for the dedicated 'nmh' user:
>
> (2) When away from your main system,
>Well, anno might be implementable via the IMAP "tags" facility, no?
Are you thinking about "flags"? I don't think they're rich enough to
emulate everything that annotations give you. I'm not sure there's
any other tagging facility in IMAP.
--Ken
Ralph Corderoy <[EMAIL PROTECTED]> writes:
> > > Well, the real crux of the problem is that there are some things
> > > that you simply cannot _do_ within the context of IMAP. The big
> > > one that comes to mind is annotations (there really isn't a way to
> > > modify messages on the server, fr
Are we making this too complex?
If we really wanted to use IMAP, we wouldn't be using 'nmh'.
I can see two possible roles for IMAP for the dedicated 'nmh' user:
(1) As a pipe, to download messages into your nmh folders. You
would really be using it much as you use POP3. You might
Hi,
> > Well, the real crux of the problem is that there are some things
> > that you simply cannot _do_ within the context of IMAP. The big
> > one that comes to mind is annotations (there really isn't a way to
> > modify messages on the server, from my reading of the
> > specification).
>
>
>See the APPEND IMAP4rev1 command:
>
>append: http://andrew2.andrew.cmu.edu/rfc/rfc1730.html#sec-6.3.10.
Yeah, I had look at this, but it really doesn't work - you can't
_replace_ an old message, you can only add a new one to a folder. You
can set a system-defined flag called \Answer that signif
> If there's no way to replace a message on the server with a local version,
> then if nmh does local caching of IMAP messages, modification of those
> messages will definitely be an issue.
See the APPEND IMAP4rev1 command:
append: http://andrew2.andrew.cmu.edu/rfc/rfc1730.html#sec-6.3.10.
It a
Ken Hornstein <[EMAIL PROTECTED]> writes:
> >IMO, it's rare because people these days don't think of being able to
> >do it; they're used to GUI mail front-ends that don't allow (?) this
> >kind of thing.
>
> Use an IMAP client recently?
Well, he made it clear that he hadn't. Lots of us nmh
13 matches
Mail list logo
