Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
On Oct 14, 2019, at 3:04 PM, Keith Medcalf wrote: > > On Monday, 14 October, 2019 14:18, Warren Young wrote: > >> Fossil Forums allow you to subscribe to email notifications. From the >> reader’s perspective, it’s really very little different from the current >> Mailman based scheme. > > The preceding paragraph is completely at odds with the following paragraph, > and taken together, they are completely illogical and inconsistent. You’re conflating inbound and outbound paths. The ability to send email implies but does not require the ability to receive email. ...Which is why they’re often entirely different stacks, speaking different protocols! E.g. SMTP outbound via Postfix, IMAP inbound via Dovecot. > All it needs is to be able to "read and process" RFC-2822 formatted message > files that are found in an "inbound for me” directory That’s certainly one way that some email servers work. The most common such scheme is called Maildir. But there’s probably at least half a dozen other ways it can work: mbox, MySQL store, PostgreSQL store, whatever it is that MS Exchange does that’s incompatible with the rest of the world… There are currently four supported outbound email setups in Fossil, and a stub for a fifth: https://fossil-scm.org/home/doc/trunk/www/alerts.md#advanced Why would inbound be different? Fossil isn’t in a position where it can require a specific SMTP server. It has to run on pretty much every common desktop and server platform. You have to get pretty far down the long tail of OSes before you find one that Fossil doesn’t get used on daily by someone. Therefore, we have to support approximately everything. On top of integrating with all common SMTP stacks, drh long ago stated a wish to write his own SMTP server. (The latter being why Fossil has the start of one included!) This should not surprise you if you’ve followed his career. :) The last time I counted up the pages of RFCs you have to implement to speak to a large fraction of the Internet email infrastructure — which was one of the times this argument came up on this mailing list! — it was something like 500 pages of standardese. It is not just RFC-2822. Getting to something useful will take time, which comes out of the time budget for SQLite, Fossil, etc. There is the option of writing glue software between Fossil and whatever SMTP infrastructure you already have, but no one’s bothered to do that in the year or so that Fossil Forums have been in steady use. To me, that speaks more of the desirability of inbound email submission than about its inherent difficulty. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
On Monday, 14 October, 2019 14:18, Warren Young wrote: >Fossil Forums allow you to subscribe to email notifications. From the >reader’s perspective, it’s really very little different from the current >Mailman based scheme. The preceding paragraph is completely at odds with the following paragraph, and taken together, they are completely illogical and inconsistent. >What Fossil Forums currently does *not* allow is posting or replying via >email. That requires either tight integration with some other SMTP mail >server so that incoming mail can be delivered to the Forum feature for >email address vetting and such, or it requires that Fossil itself has an >SMTP email server built in so it can handle it directly. All it needs is to be able to "read and process" RFC-2822 formatted message files that are found in an "inbound for me" directory, and write RFC-2822 formatted message files into an "outbound from me" directory. There is really nothing inherently difficult about that. What it does is simply read files from the inbound directory and write messages to send to the outbound directory. If it can do these things it can interact with every MTA in existence. This is how e-mail message processors work, and what almost all mailing list processors do (though some are integrated differently because being generic and Keeping It Simple Stupid is apparently not a thing). And yes, there is no reason that the part betwixt reading the inbound and writing the outbound cannot create a "Web Forum" for those so inclined. I think if you go back a couple of dozen years these sort of "gateways" were all the rage. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
On Oct 11, 2019, at 11:33 AM, Tim Streater wrote: > > A mailing list suits me just fine. It works well and gets next to no spam. In > addition, it's not yet another damn website I have to log into to use and > remember my username/password for. And I don't care if it's not "modern”. Fossil Forums allow you to subscribe to email notifications. From the reader’s perspective, it’s really very little different from the current Mailman based scheme. What Fossil Forums currently does *not* allow is posting or replying via email. That requires either tight integration with some other SMTP mail server so that incoming mail can be delivered to the Forum feature for email address vetting and such, or it requires that Fossil itself has an SMTP email server built in so it can handle it directly. There’s a start to both options in the current code base, but neither method is anywhere near production-ready. That may be one reason why this mailing list isn’t a Fossil Forum yet. We get a bunch of benefits in exchange for this loss of functionality relative to traditional mailing lists, given at the top of this doc: https://fossil-scm.org/home/doc/trunk/www/forum.wiki I’m a bit of a mailing list traditionalist myself, but I’m also quite happy with the way the Fossil Forum feature came out. I’m using it myself on my own public projects. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
On Oct 11, 2019, at 9:56 AM, Brannon King wrote: > > I'd like to propose that we > upgrade to something more modern and secure like Sympa or mlmmj, or even a > more drastic system upgrade to something like Redmine -- a project > tracker + forum. This is a really old argument, which we’ve had at least twice before. You can dig those old threads up in the archives. (Ha!) drh created Fossil Forums as his answer to the debate. The only question is how long it will take for him to decide to move the SQLite mailing lists to a Fossil Forum, not whether we’ll move to Redmine instead, or whatever. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
On Oct 11, 2019, at 9:41 AM, Mike Bayer wrote: > > what is the reason that the SQLite mailing list archives...are private for > members only in order to be read? Probably because you can extract email addresses and real names from the archives. Harvesting of such information is a problem inherent in any SMTP mailing list that wants to allow direct replies to individual members without going back through a central service, as Mailman allows. That gives three alternatives: 1. Let any bad actor harvest this info. 2. Hide the info entirely so that direct replies aren’t possible. 3. Switch to some other tech that ensures that only list members can talk directly to other list members, so that the up-front anti-spammer tech prevents the service from being used for spamming. The first two are probably options in Mailman, but they aren’t great options. > The archives can be viewed at a mirror such as > http://sqlite.1065341.n5.nabble.com/ Those mirrors usually take option #2 above. If this mailing list moves to any other service, it is likely to be to a Fossil Forum, which we’ve been using successfully within the Fossil project — a DVCS created to aid the development of SQLite — for about a year now. You can read more about this feature here: https://fossil-scm.org/home/doc/trunk/www/forum.wiki and you can see the existing forum here: https://fossil-scm.org/forum/forum That’s not for SQLite discussion. I’m pointing you to it so you can see what this mailing list may eventually become. Fossil Forums currently implement option #2 above, but I’m hoping we get #3 eventually. > Additionally, it appears that the SQLite Mailman server is configured to > suppress "reply-to" to the sender of an email. You can’t get everyone on the list to agree with The One True Way such settings must be set, so *someone* will always be unhappy with the way the list works. > making the mailing list opaque leads to user questions that are entirely > related to SQLite and nothing else being posted in downstream project > communities instead, which pushes the community response burden downwards. You’re ignoring spammers, other bad actors, GDPR… Complete transparency simply isn’t possible any more in 2019. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Slight problem compiling Tcl bindings -- can't strip .dll file
I just compiled 3.30.1 on Win 10 using msys (./configure make). I saw what seemed to be the usual "permission denied" and warning messages. As usual, I tried to strip the binary (force of habit rather than needing a smaller .dll), and got the following message: $ strip sqlite3301.dll C:\MinGW\bin\strip.exe: unable to rename 'sqlite3301.dll'; reason: Permission denied But the funniest thing is that after the attempted strip the .dll disappears. If copied before the strip, the .dll functions. Strange. Gerry Snyder ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Downside of setting SQLITE_MAX_ATTACHED to 125
On 10/14/19, szmate1618 . wrote: > Hello everyone! > > After consulting the manual and doing a little googling I'm still unsure > about the runtime cost of a high SQLITE_MAX_ATTACHED setting. I admit 10 is > a reasonable default, but it's possible that I'll need a bit more. Can I > just set it to 125 right away and stop worrying about it, without terrible > performance degradation? Any help is appreciated, even if you just point me > to a relevant part of the source code. > There is a small performance and memory penalty in sqlite3_prepare() (and its relatives) when SQLITE_MAX_ATTACHED exceeds 30. https://www.sqlite.org/src/artifact/40f81bb57b072340?ln=3065-3082 -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Downside of setting SQLITE_MAX_ATTACHED to 125
Hello everyone! After consulting the manual and doing a little googling I'm still unsure about the runtime cost of a high SQLITE_MAX_ATTACHED setting. I admit 10 is a reasonable default, but it's possible that I'll need a bit more. Can I just set it to 125 right away and stop worrying about it, without terrible performance degradation? Any help is appreciated, even if you just point me to a relevant part of the source code. Thank you very much in advance! Máté Szabó ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
