On Mon, Feb 6, 2012 at 12:51 PM, Joel Uckelman wrote:
>> If/when IMAP support is added in, mhpath will return
>> imap URLs. If one is using the existing classic storage
>> model, then local pathnames are returned.
>
> IMAP URLs aren't paths, at least not in the sense I take 'path' to have
> in 'm
>i think it's itinerant upon those who think this should be done, to walk
>the walk. i also think that intermediate products such as example API's
>and proposals should be shared with the whole list. and lastly i think
>that silence will equal assent :-).
Okay, I can see your point. I was going t
On Mon, 06 Feb 2012 11:51:04 MST, Joel Uckelman said:
> in 'mhpath'. Maybe we could add 'mhurl' to produce URLs (and file: URLs
> for local storage!) and leave mhpath producing paths?
m-hurl. What has been seen cannot be unseen. ;)
pgpLvQ2xPjlNU.pgp
Description: PGP signature
__
Thus spake Earl Hood:
> Wrt to mhpath, I think it is getting over analyzed. All
> mhpath does is provide the *path* to an nmh resource,
> that's it.
>
> Issues like fetching or not fetching are out-of-scope.
>
> If/when IMAP support is added in, mhpath will return
> imap URLs. If one is using t
paul vixie writes:
>On 2/6/2012 4:20 PM, Tethys wrote:
>> If we do so, it will of course have to allow arbitrarily deep nesting,
>> so we can address things like 53.6.4.1 (the 1st part of the 4th part of
>> the 6th part of message #53).
>
>ouch! my eyes!
Yes, but representative of real world MIM
On 2/6/2012 4:20 PM, Tethys wrote:
> If we do so, it will of course have to allow arbitrarily deep nesting,
> so we can address things like 53.6.4.1 (the 1st part of the 4th part of
> the 6th part of message #53).
ouch! my eyes!
___
Nmh-workers mailing
Wrt to mhpath, I think it is getting over analyzed. All
mhpath does is provide the *path* to an nmh resource,
that's it.
Issues like fetching or not fetching are out-of-scope.
If/when IMAP support is added in, mhpath will return
imap URLs. If one is using the existing classic storage
model, the
On 2012-02-06, at 9:09 AM, Ken Hornstein wrote:
> SETMETADATA INBOX (/private/nmh/${imap-uid}-anno "Replied: Mon, 06 Feb 2012")j
Exactly.
> As I understand it ... the limits on METADATA are per-mailbox. What are
> some typical limits?
I'm not sure. I will poll the IMAP protocol list and see
>It's not that hopeless. If the IMAP server supports the METADATA
>extension (and most modern servers do), we can almost fully support
>anno.
So ... looking at RFC 5464 ... for anno you would do something like:
SETMETADATA INBOX (/private/nmh/${imap-uid}-anno "Replied: Mon, 06 Feb 2012")
As I u
On 2012-02-06, at 8:10 AM, paul vixie wrote:
> if the underlying message store is immutable, i expect anno to do one of
> two things:
>
> 1. maintain state locally -- this means other IMAP users on the same or
> other hosts will not see anno's changes.
>
> 2. fail.
It's not that hopeless. If
On Mon, 06 Feb 2012 07:11:57 PST, Lyndon Nerenberg said:
> No, you need to download text parts. It would be pointless to download the
> 15 multi-MB TIFF attachments as well.
The fact it's text doesn't imply it needs downloading. I regularly get
logfiles from
our NetApp that run to 4M in size
paul vixie writes:
>i think we're going to end up extending the "message number" to be a
>decimal not an integer, as in "53.6" to get MIME part 6 of message
>number 53. any place that accepts a "message number" will have to
>understand this
If we do so, it will of course have to allow arbitraril
paul wrote:
> On 2/6/2012 3:58 PM, Lyndon Nerenberg wrote:
> > IMAP messages are immutable. You cannot change them after the fact.
> >
> > This us one of the many tricky issues with supporting an IMAP message
> > store.
> E.g., it will be difficult to make anno behave correctly in all cases
On 2/6/2012 3:58 PM, Lyndon Nerenberg wrote:
> IMAP messages are immutable. You cannot change them after the fact.
>
> This us one of the many tricky issues with supporting an IMAP message store.
> E.g., it will be difficult to make anno behave correctly in all cases.
if the underlying message st
>Not just download, but upload too, that is, modify messages.
IMAP messages are immutable. You cannot change them after the fact.
This us one of the many tricky issues with supporting an IMAP message store.
E.g., it will be difficult to make anno behave correctly in all cases.
__
Ken Hornstein writes:
>>In the IMAP case, you don't want to download the entire message just to
>>satisfy an mhpath request. The value in IMAP is its ability to treat
>>MIME sections as separate objects. By sucking down entire messages, all
>>you've done is downgrade IMAP to POP.
>
>I understand w
>No, you need to download text parts. It would be pointless to download
>the 15 multi-MB TIFF attachments as well.
Huh, I guess I was thinking that you had to download the whole message
body, but I guess I shouldn't go up against an IMAP expert like you :-)
I took a closer look at RFC 3501 and I
On 2012-02-06, at 6:28 AM, Ken Hornstein wrote:
> I understand where you're coming from, but I have to ask ... when
> people use mhpath to get the path of an MH message, what, exactly,
> are they trying to accomplish? Usually it's something along the
> lines of "use some Unix text processing too
On 2/6/2012 2:28 PM, Ken Hornstein wrote:
>> In the IMAP case, you don't want to download the entire message just to
>> satisfy an mhpath request. The value in IMAP is its ability to treat
>> MIME sections as separate objects. By sucking down entire messages, all
>> you've done is downgrade IMAP to
>In the IMAP case, you don't want to download the entire message just to
>satisfy an mhpath request. The value in IMAP is its ability to treat
>MIME sections as separate objects. By sucking down entire messages, all
>you've done is downgrade IMAP to POP.
I understand where you're coming from, but
On 2012-02-05, at 12:13 PM, Ken Hornstein wrote:
> % echo `mhpath 5 8 12`
> /tmp/.imapcache/88932 /tmp/.imapcache/92861 /tmp/.imapcache/1034785
>
> Or whatever ... you get the idea. mhpath would fetch the messages
> in question and put them somewhere local and return those pathnames.
> Sure, yo
21 matches
Mail list logo
