SQLite Forum

Welcome
Login

Welcome

(1) By Richard Hipp (drh) on 2020-03-12 19:52:17 updated by 1.1 [link]

This is the initial post to the newly established SQLite Forum.
The purpose of this post is to test the system to make sure I have
set it up correctly.

# About

This Forum is powered by [Fossil](https://fossil-scm.org), the
same version-control system that manages the SQLite source code.
See the [Forum Documentation](https://fossil-scm.org/fossil/doc/trunk/www/forum.wiki)
for additional information.

The intent is that this forum will eventually replace the mailing lists.

## Advantages of the Forum

  1.  Improved control of spam.

  2.  Easy for anonymous passers-by to post messages and/or view
      historical content without having
      to sign up.

  3.  Built-in search

  4.  Messages can be formatted using plain-text, Markdown, or Fossil-Wiki.
      Hyperlinks can be embedded.  The message can be previewed prior to
      posting.

  5.  Messages can be edited if mistakes are discovered after posting.

  6.  Email notification of new content is provided as an option, but is
      not required.


## Possible annoyances for people who like mailing lists

  1.  Though inbound messages arrive in your email in-box, you cannot
      reply directly via email.  You *must* visit the website in order
      to post a new message.

Welcome

(1.1) By Richard Hipp (drh) on 2020-03-12 21:59:00 edited from 1.0

This is the initial post to the newly established SQLite Forum.
The purpose of this post is to test the system to make sure I have
set it up correctly.

# About

This Forum is powered by [Fossil](https://fossil-scm.org), the
same version-control system that manages the SQLite source code.
See the [Forum Documentation](https://fossil-scm.org/fossil/doc/trunk/www/forum.wiki)
for additional information.

The intent is that this forum will eventually replace the mailing lists.

## Advantages of the Forum

  1.  Improved control of spam.

  2.  Easy for anonymous passers-by to post messages and/or view
      historical content without having
      to sign up.

  3.  Built-in search

  4.  Messages can be formatted using plain-text, Markdown, or Fossil-Wiki.
      Hyperlinks can be embedded.  The message can be previewed prior to
      posting.

  5.  Messages can be edited if mistakes are discovered after posting.

  6.  Email notification of new content is provided as an option, but is
      not required.

  7.  Mobile friendly 

## Possible annoyances for people who like mailing lists

  1.  Though inbound messages arrive in your email in-box, you cannot
      reply directly via email.  You *must* visit the website in order
      to post a new message.

(2) By anonymous on 2020-03-13 09:40:43 in reply to 1.1 [link]

Perhaps silly question, but on the [Register](https://www.sqlite.org/forum/register) page, what, if anything, do we put in for **User ID**? Do we just invent a (presumably internal) "username" (_c.f._ the external **Display Name**), and do we have to try/hope it is unique?

(3) By Richard Hipp (drh) on 2020-03-13 10:28:50 in reply to 2 [link]

IIRC, it will complain and ask you to reenter if you provide a non-unique name.

(4) By Rowan Worth (sqweek) on 2020-03-13 10:32:57 in reply to 2 [link]

FWIW when I post it's using my username rather than my display name.

(6) By Warren Young (wyoung) on 2020-03-13 13:14:47 in reply to 4 [link]

> FWIW when I post it's using my username rather than my display name.

We discussed this over on the Fossil project forum.

[One argument from drh][1] is that it's a potential privacy problem to use the display name on public web pages. (Thus the argument doesn't apply in email alerts, where the recipient's display name is used.)

Another, which I fail to find by searching, is that looking up the Display Name requires an extra DB hit. The user name is part of the forum post artifact, thus is "free" to the code generating the HTML for this page, whereas the Display Name requires indexing the `user` table by that name.


[1]: https://fossil-scm.org/forum/forumpost/cd3c0f5044a60d

(10) By Rowan Worth (sqweek) on 2020-03-16 03:15:49 in reply to 6 [link]

It's also a potential security issue to have the username (ie. account login name) publicly visible. But more to the point, the mere existence of the "Display Name" field during user creation suggests that is what will be shown to other members of the list to identify you.

Personally I'm not that fussed about which name gets used, but the user experience as it stands definitely violates the principle of least surprise.

(11) By anonymous on 2020-03-16 05:56:49 in reply to 10 [link]

I agree; it should mention in the registration form, what it is doing, so that it is more clearly.

But about the security issue, the username has to be publicly visible due to how Fossil works, and seems isn't really that much of a problem anyways.

(5) By ddevienne on 2020-03-13 11:43:33 in reply to 1.1 [link]

Just registered.  

_(Like others, I'd rather use the ML, instead of being forced to the forum...)_

On submit, didn't like the empty Display Name (why not just use the username in the case?),  
OK, I can copy/paste the username myself, but why then make me redo the captcha?   
  If I got the first one correct, I'm not a bot, so why waste everyone's time having to redo it?

(9) By anonymous on 2020-03-16 02:24:27 in reply to 5 [link]

> _(Like others, I'd rather use the ML, instead of being forced to the forum...)_

Yes, and I am one who would rather use NNTP (even if it first requires registration on the web forum, in order to allow writing with NNTP). Of course, different people will prefer differently.

> On submit, didn't like the empty Display Name (why not just use the username in the case?),

I agree; it should not require a display name (since you can use the username instead).

> OK, I can copy/paste the username myself, but why then make me redo the captcha?   
>   If I got the first one correct, I'm not a bot, so why waste everyone's time having to redo it?

Possibly something having to do with how the implementation is working. However, as far as I understand it, it should be possible by entering the same `captchaseed` value in the registration form, as the previous one.

(7) By Kevin Youren (KevinYouren) on 2020-03-13 20:51:00 in reply to 1.1 [link]

Richard, 

thank you, much appreciated.

regs,

Kev

(8) By sean (jungleboogie) on 2020-03-16 01:14:13 in reply to 1.1 [link]

See this page for markdown formatting rules:
<https://fossil-scm.org/home/md_rules>

(12) By Nathan Evans (nbevans) on 2020-03-16 09:06:39 in reply to 1.1 [link]

10+ year "nabble" lurker here that could never contribute anything as a mailing list was just too antiquated for me. Though it would probably have been easier / wiser to just deploy an instance of say Discourse than build your own forum software. There is going to be a constant stream of requests to improve the forum now for years as a result of this decision :)

(13) By Tim Streater (Clothears) on 2020-03-16 10:23:39 in reply to 12 [link]

Where are my preferences? I want to be able to set:

1) Always display posts in chronological order

2) Always formatted

3) For post composition and replies, always plain text.

Where do I set these?

(14) By Stephan Beal (stephan) on 2020-03-16 10:32:56 in reply to 13 [link]

The forum does not currently have infrastructure for keeping track of per-user preferences beyond their notification preferences.

(17) By anonymous on 2020-03-16 16:00:41 in reply to 13 [link]

You could possibly use a GreaseMonkey script to change links and form fields to your preferences, if you want to, I suppose. (You could also use this to add access keys like I want, if you want that feature too.)

(15) By Richard Hipp (drh) on 2020-03-16 14:18:49 in reply to 12 [link]

> ... just deploy an instance of say Discourse \[rather\] than build your own forum software...

SQLite is built using a lot of home-grown infrastructure

  *  The Lemon LALR(1) parser generator rather than Yacc/Bison
  *  Fossil rather than Git/Hg
  *  And now the new Forum rather than a prepackaged system like Discourse.

It is a recurring theme that this is bad and that I should be using
third-party "standard" components.  But in my experience, the use of 
home-grown components has been a great boon for SQLite.  Fossil in
particular has been enormously helpful in moving SQLite forward.

Fossil, in addition to being the VCS used by SQLite, is also the main
beta-test project for SQLite.  It is very important that I be closely
involved in the on-going development and support of Fossil because Fossil
uses SQLite extensively, and that puts me in the position of being an
SQLite user instead of an SQLite developer.  When I am in the position
of an SQLite user, I more easily appreciate the pain-points that users
experience, so that the next time I switch back over to the SQLite
developer role, I am more motivated to address those pain-points. Problems
are fixed and new features are added more quickly when they affect Fossil.

So, in other words, I am not wasting time working on the Forum software.
This new Forum is built around SQLite, and so working on it helps me to
stay in touch with the experience of users of SQLite, which is important
for keeping SQLite working smoothly.

A few people report that the transition from legacy mailing-list to a
forum system is annoying&sup1;.  That is not the intent of the transaction,
but rather an undesirable side-effect.  The transition is designed to
help make SQLite a better product, and will (it is hoped) be a net
positive in the long-run.

----
&sup1;In private communications, far more people have welcomed the
transition than have denegrated it.

(18) By Warren Young (wyoung) on 2020-03-16 17:12:21 in reply to 15 [link]

> SQLite is built using a lot of home-grown infrastructure

Also [`althttpd`](https://www.sqlite.org/docsrc/doc/trunk/misc/althttpd.md).

(16) By anonymous on 2020-03-16 15:47:13 in reply to 12 [link]

I dislike Discourse, so am glad you don't use it.

(19) By Ryan Smith (cuz) on 2020-03-24 09:54:54 in reply to 1.1 [link]

I've watched the Forum vs. Mailing list debate with a measure of ambivalence, thinking I don't mind it either way.

Having negotiated the forum now for a bit I have to say I like it, I even like the display style which some contributors questioned.

There are however two glaring faults which I think could be easily fixed to make it a complete functional replacement for the mailing list.

Firstly: My mail messages now only contain the posted message, none of the context, only gaining contextual meaning once the link is clicked. It's completely useless as a text, it could well be replaced with a "There's a new post! - click here." flag.

How about, in the outgoing mail, programmatically including the previous 2 messages in the thread at the least, or perhaps the ellipsed first 500 characters of the previous 5 messages with simple separators (or ellipses between 300 starting+300 ending characters - a quick bit of testing should reveal a good format). Both these would solve the issue (or perhaps other solutions I haven't even thought about).

Secondly, frustratingly I am all for freedom and allowing anonymous posting, but it makes it very hard to establish weight to a post. Sometimes I see posted solutions from Anonymous people, which may or may not be good solutions, but now I have to do further reading on the matter... whereas if I knew it was from Keith or Igor or James or... or... I could immediately 5-star that content in my mind and use it or move on. The opposite is also true.

From a poster's perspective, it's also hard to notice when you open the site if you are in anonymous mode or not, so I could easily post as anonymous, perhaps making people think my post has more value than it actually deserves or robbing them of the ability to simply click past my post when they already know they don't like what I say (or the length with which I say it). It would be nice if the site reminded me "You need to log in to post".

Can we please not have anonymous posting? It's not like we vet a poster's heritage... a simple incognito but perpetually recognizable handle would do.


With these fixed, I would stop missing the mailing list so dearly.
Thanks.

(20) By Wout Mertens (wmertens) on 2020-03-24 14:40:54 in reply to 19 [link]

Actually, I like that the messages are only the message and none of the thread, it saves on resource usage. I have a threading email client (the GMail web interface), I only archive emails so I always have the context locally.

I like how the forum works and how fast it is. My only gripe is that emails are sent immediately, and then when a poster edits their post that sends another email. I'd prefer some delay, so posting only sends an email after 30s or so, and if you start editing the post it delays it for 5 minutes or until you save + 30s.

(21) By Tim Streater (Clothears) on 2020-03-24 14:57:44 in reply to 20 [link]

The fundamental question is, is there any intent to develop the forum software, or not. If not, no point in making feature requests. If the management is open to putting in effort there, there'd be scope for having a feature request list.

(23) By Richard Hipp (drh) on 2020-03-24 15:15:36 in reply to 21 [link]

The [Fossil Forum][ff] is a better venue for discussing feature requests
for the forum software itself, I think.  That avoids cluttering the inbox
of people who only want to hear about SQLite.

We are quite open to suggestions, and especially patches, for improving
the forum software.  One of the (unmentioned) advantages of Forum over
mailing-list is that is under more control of the development team.  We
are no longer dependent on a third-party provider for improvements - we
can make them ourselves.

Note that since the forum software is BSD-licensed instead of public domain
like SQLite, it is much easier for people to contribute patches.  We will
need a Contributors License Agreement from the patch provider, certifying
that the contributed patch complies with the BSD license.  But the extensive
documentation needed before contributing to the public domain is avoided.
There are many more contributors to Fossil than to SQLite, therefore.  You
are welcomed to increase that number.

[ff]: https://fossil-scm.org/forum

(25) By Tim Streater (Clothears) on 2020-03-24 19:21:52 in reply to 23 [link]

I'll have a look there. It's unlikely I'd be contributing patches, it's nearly 30 years since I wrote any C. C-like languages, PHP, javascript, perhaps, but that's all.

I'll stick to suggestions and leave it at that.

(22) By Ryan Smith (cuz) on 2020-03-24 14:58:56 in reply to 20 [link]

I see how it can work for you, but you appreciate that the "Answer" to the now deficit of context for those of us who do not use GMAIL cannot be (or at least, should not be): "Use better mail-reading software please."

It's also hard to imagine a less impactful "resource-saving" than a few lines of text in a time when viral video spam abound.

Now the entire point of having an online archive becomes moot if I still have to "store" all mails local so that my mail software (assuming I upgraded) can build threads from history.

I think receiving a mail in which the previous few posts (no need for the whole thread) were quoted or simply quoted in part to restore the context, would be a real help without any meaningful resource impact and most assuredly programmatic simplicity. Perhaps even a toggle if one prefers not to receive such.

Currently though, this deficit takes away, at least for me, one of the real benefits the mailing list had.

(24) By Keith Medcalf (kmedcalf) on 2020-03-24 17:51:46 in reply to 22 [link]

Insinuating that the GMail is "better mail-reading software" is flabbergasting!

(26) By Warren Young (wyoung) on 2020-03-25 01:49:01 in reply to 20 [link]

> I'd prefer some delay, so posting only sends an email after 30s or so

I've started [a new thread on the Fossil forum][1]. Let us to continue this sub-thread there.

[1]: https://fossil-scm.org/forum/forumpost/8b84aa444a

(27) By sqliteFan on 2020-09-23 03:23:06 in reply to 1.1 updated by 27.1 [link]

Hello, Richard Hipp, about ANALYZE, I have a question, why can't call sqlite3BtreeRowCountEst() for tables with only rowid without other indexes?
I think invoking sqlite3BtreeRowCountEst () increases efficiency for large table.
See code comments:
static void analyzeOneTable(){
...
    for(pIdx=pTab->pIndex; pIdx; pIdx=pIdx->pNext){
        ...
        addrRewind = sqlite3VdbeAddOp1(v, OP_Rewind, iIdxCur);
        VdbeCoverage(v);
        sqlite3VdbeAddOp3(v, OP_Count, iIdxCur, regTemp, 1); //will call sqlite3BtreeRowCountEst()
    }
    ...
    if( pOnlyIdx==0 && needTableCnt ){
        ...
        VdbeComment((v, "%s", pTab->zName));
        sqlite3VdbeAddOp2(v, OP_Count, iTabCur, regStat1); //will call sqlite3BtreeCount()
        jZeroRows = sqlite3VdbeAddOp1(v, OP_IfNot, regStat1); VdbeCoverage(v)
    }
}

(27.1) By sqliteFan on 2020-09-23 05:49:42 edited from 27.0 in reply to 1.1 [link]

Hello, Richard Hipp, about ANALYZE, I have a question, why can't call sqlite3BtreeRowCountEst() for tables with only rowid without other indexes?
I think invoking sqlite3BtreeRowCountEst() increases efficiency for large table.
See code comments:
static void analyzeOneTable(){
...
    for(pIdx=pTab->pIndex; pIdx; pIdx=pIdx->pNext){
        ...
        addrRewind = sqlite3VdbeAddOp1(v, OP_Rewind, iIdxCur);
        VdbeCoverage(v);
        sqlite3VdbeAddOp3(v, OP_Count, iIdxCur, regTemp, 1); //will call sqlite3BtreeRowCountEst()
    }
    ...
    if( pOnlyIdx==0 && needTableCnt ){
        ...
        VdbeComment((v, "%s", pTab->zName));
        sqlite3VdbeAddOp2(v, OP_Count, iTabCur, regStat1); //will call sqlite3BtreeCount()
        jZeroRows = sqlite3VdbeAddOp1(v, OP_IfNot, regStat1); VdbeCoverage(v)
    }
}