Maybe time for a new release?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Maybe time for a new release?

Ken Hornstein-2
I've been itching to do some MIME refactoring, and by "refactoring" I
mean completely doing a new message/MIME parser from the ground up,
based on flex/bison (at least parse headers using flex, maybe address
parsing via bison ... we'll see) and have a completely new internal API.
See "full MIME integration" email and "vague, undefined thoughts on nmh
MIME processing" in the archives if you want an idea.

But ... the Real World™ keeps getting in the way.  And this (at least in
my mind) is going to be a major shakeup.  Which makes me think before we
completely change the world, maybe we should cut a new release.  The
last release was in June of 2014, and while I haven't been doing much
in that time David Levine has been quietly adding new features and stomping
on bugs.  So maybe it makes sense to draw a line in the sand now and say,
"Hey, this is the last release under the old MIME code".  Or if that
doesn't happen, we'll do another "last release".  Or we'll just keep
limping along with our crappy MIME code (I sure hope not).

The two things I think that should be worked on for a new release is
fixing the problem when during message display iconv() fails to convert
a character (just substitute a '?' is fine, I think) and bringing over
the XOAUTH2 code that Eric Gillespie did (I've been meaning to do it
because it is a lot of work that I'd hate to lose).  The first issue,
at least, should be easy.

What do people think of this idea?  If you like this idea, is there
anything else you want fixed before a new release?  I am thinking this
would have enough to be called 1.7.

--Ken

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Kevin Cosgrove-2

On 8 March 2016 at 19:25, Ken Hornstein <[hidden email]> wrote:
 
> What do people think of [Ken's] idea [to gather appropriate
> changes since the last release for a "1.7" release, followed
> by a MIME refactoring project]?  If you like this idea, is
> there anything else you want fixed before a new release?  I am
> thinking this would have enough to be called 1.7.

Ken, I think that's a great way to politely move forward, AND
make some headway toward sensibly keeping pace with the MIME
environment.  I don't have any "must have now" items on my
list for 1.7.

Thanks for the suggestion....

--
Kevin



_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Paul Vixie-2
where did we end on reformatting the mhdir to accommodate MIME?

in the past, a simple line oriented UNIX utility such as "grep -r" could
be used on the mhdir, with good results. with MIME that's no longer
true, either because of quoted-printable, base64, or nested objects.

one solution proposed for this was to add some new helper tools similar
to find(1) and/or xargs(1) which could execute line-oriented tools
within the context of defanged and decoded content.

another solution proposed would write defanged/decoded content into
files that are stored alongside the original (as received in SMTP)
content. some new option to "folder" or "sortm" could generate these for
older mhdirs, whereas inc and rcvstore would just write both forms.

i think i favoured both approaches :-). was there an end to the argument?

vixie

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Ken Hornstein-2
>in the past, a simple line oriented UNIX utility such as "grep -r" could
>be used on the mhdir, with good results. with MIME that's no longer
>true, either because of quoted-printable, base64, or nested objects.
>
>one solution proposed for this was to add some new helper tools similar
>to find(1) and/or xargs(1) which could execute line-oriented tools
>within the context of defanged and decoded content.
>
>another solution proposed would write defanged/decoded content into
>files that are stored alongside the original (as received in SMTP)
>content. some new option to "folder" or "sortm" could generate these for
>older mhdirs, whereas inc and rcvstore would just write both forms.
>
>i think i favoured both approaches :-). was there an end to the argument?

Well ... no?  I mean, I didn't view it as an argument, myself.  But let
me be clear: nothing I am planning on doing involved changing the MH
store.  Nothing I am planning on doing would PRECLUDE that, it's just
that I didn't view it as part of my scope.

Let me explain my larger view.  I know lots of people still want to be
able to use Unix text processing utilities on a MH store.  But I hate
to be the the one who has to explain this ... that hasn't been a realistic
goal since the advent of MIME.  The model that "email is text" just
isn't valid anymore.

Now, I know you and most everybody _know_ this, Paul ... but you haven't
really accepted what it means.  What it means to me is that you can't
really expect to use Unix text processing tools on RFC 5322-format files;
they don't meet the definition of "text" by any stretch of the imagination,
and different parts of the file can have different encoding schemes and
character sets (and parts aren't even guaranteed to contain human-readable
text).  So to me, trying to use Unix text processing tools on RFC-5322
format files in 2016 is simply a fool's errand.  Yeah, it may work fine ...
but you're guaranteed to have it not work at some point.  And we can't
really fix that without breaking a long-standing guarantee.  I know, I
know ... it was written on stone tablets, brought down from Mountain View
by Marshall Rose at the dawn of the First Age, that "MH files are text
files!".  Those tablets were pretty much smashed by Nathaniel Borenstein
in the Second Age.  (I think now we're in the Third Age).

Slightly more seriously ... email != text, that's pretty much a given
today.  If we want to have the MH store consist of "email", then it can't
be text.  If we want to change the concept of what an MH store is, then
that would break a lot of third-party tools.

So, getting around to my larger point ... my goal here is to make it
so all of the MIME tools natively deal with MIME.  That means the
standard internal API is MIME-aware, things like %{body} in scan(1) are
MIME-aware (it could be the decoded version of the first text part), and
"pick" would know how to search inside a MIME-encoded text part after
converting everything to the native character set.  You get the idea.
This requires a new API, parsing routines, etc etc ... that's the part
I'd like to work on.

Now people have suggested doing something like storing each MIME part in
it's own file, somewhere in a directory corresponding to each message.
I'm not exactly OPPOSED to that, per se ... I think it would be a lot of
work for relatively little gain, when (for instance) if I got the "new
MIME" code working, you could search through email fine with pick(1).  I
don't recall a suggestion about helper tools a la find(1) and/or xargs,
but that could just be my memory going; I'm not sure how that would
work.  I think we need to do the "new MIME" architecture to make things
better in the long run, so I view this as orthogonal to having a Unix
text processing-friendly store.  Since I personally view the text
processing-friendly store as redundant, it's not something I want to spend
my free time on.  I think the "new MIME" interface would make doing that
easier, as the code to extract those files would be simpler.

So, I guess the TL;DR answer is:

- There were lots of ideas, but nothing concrete in terms of people
  volunteering to write code.
- I wasn't planning on doing anything like that as part of my work.
  My work wouldn't stop that and might make it easier.

--Ken

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Lyndon Nerenberg (VE6BBM/VE7TFX)

> On Mar 8, 2016, at 6:19 PM, Ken Hornstein <[hidden email]> wrote:
>
> Let me explain my larger view.  I know lots of people still want to be
> able to use Unix text processing utilities on a MH store.  But I hate
> to be the the one who has to explain this ... that hasn't been a realistic
> goal since the advent of MIME.  The model that "email is text" just
> isn't valid anymore.

No, that's not true. We could decode on inc(1) to UTF-8. Every other MUA (effectively) does that these days.

Yes, I have argued for and against this in the past, specifically against the crypto-signature-breakage.  But really, what are the odds?  I would rather we decode all the MIME-encoding crap, and wherever possible, translate text/* to utf-8 according to the charset parameter indications in the mime part.  This means grep(1) continues to work.

I will deal with grep facing binary message blobs.  I can strings <msg> | grep foo to get around that.  Strings can't fix QP or base64.

--lyndon


_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Lyndon Nerenberg (VE6BBM/VE7TFX)
In reply to this post by Paul Vixie-2

> On Mar 8, 2016, at 4:58 PM, Paul Vixie <[hidden email]> wrote:
>
> another solution proposed would write defanged/decoded content into files that are stored alongside the original (as received in SMTP) content. some new option to "folder" or "sortm" could generate these for older mhdirs, whereas inc and rcvstore would just write both forms.

upas in plan9 solved that ages ago, and it's wonderful.  but it will *never* port to unix.  the best we can hope for is to turn the message file into the closest approximation of 'grep-able' text as we can.

--lyndon


_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Ken Hornstein-2
In reply to this post by Lyndon Nerenberg (VE6BBM/VE7TFX)
>No, that's not true. We could decode on inc(1) to UTF-8. Every other MUA
>(effectively) does that these days.

Sigh.  That doesn't help with image/jpeg, video/mpeg, application/pdf ...
all of those things which are not text.  That's really my point.  It
doesn't even really help that much with text/html.  And converting to
UTF-8 is only a win _if_ your local character set is UTF-8.  We have
plenty of people for whom it is not.  And I honestly do not believe that
other MUAs convert to UTF-8 upon incorporation; from what I've seen, they
store them internally in the on-the-wire format.

>Yes, I have argued for and against this in the past, specifically
>against the crypto-signature-breakage.  But really, what are the odds?
>I would rather we decode all the MIME-encoding crap, and wherever
>possible, translate text/* to utf-8 according to the charset parameter
>indications in the mime part.  This means grep(1) continues to work.

I think changing the message store to not be RFC-5322-format files is a)
unfriendly (since that's been the assumption by all of the MH/nmh tools
and their frontends since forever), and b) will have lots of unintended
consequences.  From where I'm sitting it's a poor tradeoff just to make
grep(1) work (and saying that grep(1) 'continues' to work is ... not
accurate; I do not believe you can say that it works today).  And I can
say that for me, at least, the issue of crypto-signatures breaking is
not a theoretical concern; I have a need for S/MIME support, and that's
something I was planning on working on.

If the goal is to get grep(1) working, like I said, I'm fine with some
of the schemes proposed where there is an ancillary set of files that
are Unix text format.

--Ken

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Lyndon Nerenberg (VE6BBM/VE7TFX)

> On Mar 8, 2016, at 6:45 PM, Ken Hornstein <[hidden email]> wrote:
>
> Sigh.  That doesn't help with image/jpeg, video/mpeg, application/pdf ...
> all of those things which are not text.

And unless you know something very slick, nobody has ever been able to grep those.
_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Lyndon Nerenberg (VE6BBM/VE7TFX)
In reply to this post by Ken Hornstein-2

> On Mar 8, 2016, at 6:45 PM, Ken Hornstein <[hidden email]> wrote:
>
> And converting to
> UTF-8 is only a win _if_ your local character set is UTF-8.

It's time to ditch locales.  Make the native format utf8, and convert back if you insist.  Really, you know this is true.


_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Lyndon Nerenberg (VE6BBM/VE7TFX)
In reply to this post by Ken Hornstein-2

> On Mar 8, 2016, at 6:45 PM, Ken Hornstein <[hidden email]> wrote:
>
> It
> doesn't even really help that much with text/html.

But when MUAs follow the guidelines, there will be an equivalent text/plain to do with that text/html, so the match will happen.

If not, that's not nmh's problem.
_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Ken Hornstein-2
In reply to this post by Lyndon Nerenberg (VE6BBM/VE7TFX)
>> And converting to UTF-8 is only a win _if_ your local character set is
>> UTF-8.
>
>It's time to ditch locales.  Make the native format utf8, and convert
>back if you insist.  Really, you know this is true.

It's not me you have to convince, it's everyone else.

--Ken

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Jerrad Pierce-2
In reply to this post by Lyndon Nerenberg (VE6BBM/VE7TFX)
If the goal is to have grep-able messages easily,
two things come to mind:

1) my previous MIME-hooks scripts, which save the original
message as #.msg, and then use mhmimefix to massage the message
into something more human friendly. These can easily be extended.

Or, you could just add your own add-hook to convert message
character sets however you choose.

2) Use ack <http://beyondgrep.com>, and add some filters for
RFC5322 files if there isn't one already.

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Paul Vixie
In reply to this post by Ken Hornstein-2

On Tuesday, March 8, 2016 9:19:57 PM PST Ken Hornstein wrote:

> ... I hate

> to be the the one who has to explain this ... that hasn't been a realistic

> goal since the advent of MIME. The model that "email is text" just

> isn't valid anymore.

 

i know. which is why i don't see much value in the mhdir layout. if we're not going to go after it with "grep -r" any more, then we should consider using Maildir format instead, for all of its advantages. (also i'd love to have good command line tools for managing maildirs, my wife's inbox has to be archived annually, which today i do via Thunderbird, which bites.)

 

you won't believe what you said next, though!

 

> ... So to me, trying to use Unix text processing tools on RFC-5322

> format files in 2016 is simply a fool's errand. Yeah, it may work fine ...

> but you're guaranteed to have it not work at some point. And we can't

> really fix that without breaking a long-standing guarantee.

 

that guarantee is helping precisely nobody now. whether mail is or isn't text, or whether mail is or isn't a file, makes no difference to anyone if the only way to access it is via the MH commands and/or library.

 

it might as well me in berkeley db at this stage. or maildir. or IMAP.

 

the only advantage is that the files i accumulated for 25 years in ~/Mail are immutable, except where they aren't like anno(1). and i guess there's some benefit to not having to convert them to a new format, except i already do, since i want to access them in IMAP, which means i have to convert them to Maildir.

 

so, while i appreciate the design level purity of just wanting a better API and let's not also fiddle with the on-disk format, i argue that you're preserving a benefit that no longer exists, because nothing other than your API is going to be able to access this data.

 

you seem uncertain of this, however:

 

> ... If we want to have the MH store consist of "email", then it can't

> be text. If we want to change the concept of what an MH store is, then

> that would break a lot of third-party tools.

 

the only third party tools that are still working are those which understand on-disk MIME (as received over SMTP). of those, the only ones that will break will be those which do not adopt your new API.

 

how many tools is that? as far as i know: just the various MH-only graphical shells. i don't see those as a growth area in information technology. new graphical e-mail shells use IMAP, and the on-disk format used by MH is somewhat incompatible with IMAP, as those of us who spent 25 years keeping uw-imapd working for MH can explain in some detail. (sequences? sortm? folder --pack? PFA!)

 

>

> So, getting around to my larger point ... my goal here is to make it

> so all of the MIME tools natively deal with MIME. That means the

> standard internal API is MIME-aware, things like %{body} in scan(1) are

> MIME-aware (it could be the decoded version of the first text part), and

> "pick" would know how to search inside a MIME-encoded text part after

> converting everything to the native character set. You get the idea.

> This requires a new API, parsing routines, etc etc ... that's the part

> I'd like to work on.

 

please don't let me dissuade you. nmh would be much cleaner with what you're proposing.

 

> ... I

> don't recall a suggestion about helper tools a la find(1) and/or xargs,

> but that could just be my memory going; I'm not sure how that would

> work. ...

 

imagining for a moment that something somebody wants to do can't be done with pick or rmm or refile even with a new, better, and universal MIME API, i think we need some outreach to UNIX command line tools, like an option to mhpath or mhstore that uses FUSE or even temporary files to offer a read only set of paths that "xargs egrep" would work for.

 

> So, I guess the TL;DR answer is:

>

> - There were lots of ideas, but nothing concrete in terms of people

> volunteering to write code.

> - I wasn't planning on doing anything like that as part of my work.

> My work wouldn't stop that and might make it easier.

 

thank you for explaining. if you hear about an MH-similar set of commands that works on Maildir stores, please point it my way. less and less of my archives are still in MH format.

 

--

P. Vixie


_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Ken Hornstein-2
>> ... I hate
>> to be the the one who has to explain this ... that hasn't been a realistic
>> goal since the advent of MIME.  The model that "email is text" just
>> isn't valid anymore.
>
>i know. which is why i don't see much value in the mhdir layout. if
>we're not going to go after it with "grep -r" any more, then we should
>consider using Maildir format instead, for all of its advantages.
>(also i'd love to have good command line tools for managing maildirs,
>my wife's inbox has to be archived annually, which today i do via
>Thunderbird, which bites.)

From what I've seen of Maildir, the big disadvantage is that there isn't
a good way to map MH message numbers (I'm assuming we still have them)
to Maildir filenames.  That seems solvable somehow.  But the main gain
of Maildir seems to be lack of locking requirements ... am I missing
something?  Is it more about interoperability with other software?

>that guarantee is helping precisely nobody now. whether mail is or
>isn't text, or whether mail is or isn't a file, makes no difference
>to anyone if the only way to access it is via the MH commands and/or
>library.
>
>it might as well me in berkeley db at this stage. or maildir. or IMAP.

Well ... I see your point. Let's put a pin in it for now.

>so, while i appreciate the design level purity of just wanting a better
>API and let's not also fiddle with the on-disk format, i argue that
>you're preserving a benefit that no longer exists, because nothing
>other than your API is going to be able to access this data.
>
>you seem uncertain of this, however:
>
>> ... If we want to have the MH store consist of "email", then it can't
>> be text.  If we want to change the concept of what an MH store is,
>> then that would break a lot of third-party tools.
>
>the only third party tools that are still working are those which
>understand on-disk MIME (as received over SMTP). of those, the only
>ones that will break will be those which do not adopt your new API.
>
>how many tools is that? as far as i know: just the various MH-only
>graphical shells. i don't see those as a growth area in information
>technology. new graphical e-mail shells use IMAP, and the on-disk
>format used by MH is somewhat incompatible with IMAP, as those of us
>who spent 25 years keeping uw-imapd working for MH can explain in some
>detail. (sequences? sortm? folder --pack? PFA!)

I see where you going, there are a few (I am using one right now).

>> So, getting around to my larger point ... my goal here is to make it
>> so all of the MIME tools natively deal with MIME.  That means the
>> standard internal API is MIME-aware, things like %{body} in scan(1)
>> are MIME-aware (it could be the decoded version of the first text
>> part), and "pick" would know how to search inside a MIME-encoded text
>> part after converting everything to the native character set.  You
>> get the idea.  This requires a new API, parsing routines, etc etc ...
>> that's the part I'd like to work on.
>
>please don't let me dissuade you. nmh would be much cleaner with what
>you're proposing.
>
>> ... I don't recall a suggestion about helper tools a la find(1)
>> and/or xargs, but that could just be my memory going; I'm not sure
>> how that would work. ...
>
>imagining for a moment that something somebody wants to do can't be
>done with pick or rmm or refile even with a new, better, and universal
>MIME API, i think we need some outreach to UNIX command line tools,
>like an option to mhpath or mhstore that uses FUSE or even temporary
>files to offer a read only set of paths that "xargs egrep" would work
>for.
>
>> So, I guess the TL;DR answer is:
>>
>> - There were lots of ideas, but nothing concrete in terms of people
>> volunteering to write code. - I wasn't planning on doing anything
>> like that as part of my work.  My work wouldn't stop that and might
>> make it easier.
>
>thank you for explaining. if you hear about an MH-similar set of
>commands that works on Maildir stores, please point it my way. less and
>less of my archives are still in MH format.

Is the real goal to search a Maildir store, or an IMAP store?  The latter
is something I've been thinking about on and off for a while noe.  That should
be relatively straigtforward to implement.

--Ken

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Paul Vixie-2


Ken Hornstein wrote:
> > ...
> Is the real goal to search a Maildir store, or an IMAP store?  The latter
> is something I've been thinking about on and off for a while noe.  That should
> be relatively straigtforward to implement.

i'd like something close to the full command line power of MH, when
dealing with either a local Maildir store, or a remote IMAP store.

message numbers are, indeed, "the problem." when i asked mark crispen
why IMAP was so hostile to the message numbering concepts of MH, he
muttered something about MM.

--
P Vixie

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Lyndon Nerenberg (VE6BBM/VE7TFX)

> On Mar 8, 2016, at 7:30 PM, Paul Vixie <[hidden email]> wrote:
>
> message numbers are, indeed, "the problem." when i asked mark crispen why IMAP was so hostile to the message numbering concepts of MH, he muttered something about MM.

But he did buy into, and accept, the UID concept.  We had that conversation in Steveston.  After a lot of good, local, beer.
_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Michael Richardson-5
In reply to this post by Ken Hornstein-2

+5 for a new release.

Ken Hornstein <[hidden email]> wrote:
    >> No, that's not true. We could decode on inc(1) to UTF-8. Every other
    >> MUA (effectively) does that these days.

    > Sigh.  That doesn't help with image/jpeg, video/mpeg, application/pdf
    > ...  all of those things which are not text.  That's really my point.

Yeah, but today, I can't grep those, and I wind up with false positives in
the base64.  (I claim that any <10 character sequence of ascii will always
appear somewhere in your base64 encoding, rather akin to the expansion of of
pi theories..)

So, it's a win to me.

BTW: when I grep my inbox, it's usually like:
     grep kenh ,?? ,???

because I deleted something yesterday I should have kept...

    >> Yes, I have argued for and against this in the past, specifically
    >> against the crypto-signature-breakage.  But really, what are the odds?
    >> I would rather we decode all the MIME-encoding crap, and wherever
    >> possible, translate text/* to utf-8 according to the charset parameter
    >> indications in the mime part.  This means grep(1) continues to work.

    > I think changing the message store to not be RFC-5322-format files is
    > a) unfriendly (since that's been the assumption by all of the MH/nmh
    > tools and their frontends since forever), and b) will have lots of
    > unintended consequences.  From where I'm sitting it's a poor tradeoff
    > just to make grep(1) work (and saying that grep(1) 'continues' to work

So, my preference is to have the original message in mailbox/1, and the
broken out stuff in mailbox/1.d/p1, etc.
It should be acceptable to have just the 1.d/p1.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [


_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

signature.asc (474 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Michael Richardson-5
In reply to this post by Ken Hornstein-2

Ken Hornstein <[hidden email]> wrote:
    > them) to Maildir filenames.  That seems solvable somehow.  But the main
    > gain of Maildir seems to be lack of locking requirements ... am I
    > missing something?  Is it more about interoperability with other
    > software?

It's mostly about interoperability to me.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [


_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

signature.asc (474 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Michael Richardson-5
In reply to this post by Lyndon Nerenberg (VE6BBM/VE7TFX)

Lyndon Nerenberg <[hidden email]> wrote:
    >> message numbers are, indeed, "the problem." when i asked mark crispen
    >> why IMAP was so hostile to the message numbering concepts of MH, he
    >> muttered something about MM.

    > But he did buy into, and accept, the UID concept.  We had that
    > conversation in Steveston.  After a lot of good, local, beer.

So, each message has a (U?)UID?  Are the integers a subset of that?
If we never repack a folder, do we win?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [


_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

signature.asc (474 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Maybe time for a new release?

Lyndon Nerenberg (VE6BBM/VE7TFX)
> So, each message has a (U?)UID?  Are the integers a subset of that?

UIDs increase monotonically within a folder.  Sequence numbers are
just the index number into the dynamic array that represents the current
set of messages visible withing a folder. UIDs never change (for all
practical purposes), whereas sequence numbers change all the time.

--lyndon


_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
123