On Fri, 18 Mar 2022 at 12:36, Daniel Gruno <[email protected]> wrote: > > On 17/03/2022 00.17, sebb wrote: > > On Wed, 16 Mar 2022 at 20:50, <[email protected]> wrote: > >> > >> This is an automated email from the ASF dual-hosted git repository. > >> > >> humbedooh pushed a commit to branch master > >> in repository > >> https://gitbox.apache.org/repos/asf/incubator-ponymail-foal.git > >> > >> > >> The following commit(s) were added to refs/heads/master by this push: > >> new 3a1aff5 clear up some limitations > >> 3a1aff5 is described below > >> > >> commit 3a1aff5777c2abe7970642ad1c7c7cb6240b9a6d > >> Author: Daniel Gruno <[email protected]> > >> AuthorDate: Wed Mar 16 21:49:37 2022 +0100 > >> > >> clear up some limitations > > > > -1 > > > > Some of the limitations have not been addressed. > > > >> --- > >> README.md | 13 +++++++------ > >> 1 file changed, 7 insertions(+), 6 deletions(-) > >> > >> diff --git a/README.md b/README.md > >> index 7668d5e..cfd140f 100644 > >> --- a/README.md > >> +++ b/README.md > >> @@ -47,16 +47,17 @@ Migration of the old database is required, and most of > >> the older ID generators h > >> been dropped in favor of collision-secure generators._ > >> > >> ### Known Limitations: > >> -* Not currently suitable as a list archive, as not all emails received > >> for a list are stored. > > > > That limitation is still true, AFAICT. > > If you have this assumption, please provide some evidence. I find it > very discouraging to both devs and users if we write "don't use this > software".
We need to be clear on the limitations of the software. If they don't apply to the user, then fine, they can use it. > > > >> * If an email is re-imported or archived, entries are currently replaced. > >> This can result in loss of attributes such as alternate Permalinks and > >> deleted status. > >> -* The migration tool drops Permalinks if two existing entries point to a > >> sufficiently similar email > >> -* The migration tool does not fix up badly-parsed message-ids etc > >> -* There is no longer a 1-to-1 relationship between mbox and source > >> entries. > >> - This can result in orphan source entries, with implications for privacy > >> redaction. > >> * emails are filed according to the Date: header, rather than arrival > >> time. > >> This can cause emails to appear in the wrong month or year, or even be > >> future-dated. > >> * Whilst the underlying database can handle any number of emails in a > >> month, > >> - the UI and much of the API cannot, and are not scalable. > >> + the UI and much of the API does not scale well beyond around 10,000 > >> emails per month per list. > > > > The UI is not really usable for browsing anything other than a few > > hundred emails per month. > > Above a certain limit it breaks down completely, as not all mails are > > returned. > > Above 10,000 emails perhaps, or whatever is configured. If the limit is set too high, it is likely to break clients or at least cause serious memory issues, as all emails have to be returned. I fixed that limitation for downloads by using stream output, but the UI still has to grab everything. This is fixable, but at present it is a limitation, which is why it needs to be documented. > I personally see no issues with loading up a month with 6,000 emails in > it. What do you mean when you say it's not useable above a few hundred > emails? The GUI shows about 25 emails per page on a desktop; far fewer than that on a mobile device. The only option for browsing all emails is to do so one page at a time. It will take ages to get to the last page of a list than has more than a few hundreds of emails. Furthermore, if you do manage to get to the last page of such a list, if you display a thread or source of an email, on return you will be taken back to the first page. Compare this with mod_mbox, which not only allows direct navigation to individual pages, it also allows them to be sorted by date or sender. It's reasonably easy to get to any part of a month by estimating the page number and adjusting as necessary. This could potentially be fixed, but at present it is a limitation compared with other solutions. > > > >> + > >> +#### Known limitations when migrating from older Pony Mail instances: > >> +* The migration tool can drop Permalinks if two existing entries point to > >> a sufficiently similar email > >> +* The migration tool does not fix up badly-parsed message-ids etc > >> +* There is no longer a 1-to-1 relationship between mbox and source > >> entries. > >> + This can result in orphan source entries, with implications for privacy > >> redaction. > >> * Header parsing is stricter than before; in particular some unusual > >> Message-IDs are not handled correctly. > >> This affects use of Foal as a replacement for Apache mod_mbox mail > >> archives. >
