Re: [sqlite] New SQLite Forum requires Javascript?
Richard Hipp wrote: Please try again. Thanks, this change allows me to read the articles. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] New SQLite Forum requires Javascript?
Richard Hipp wrote: As far as I know, the forum only uses javascript to scroll to the most recent posting when you load a new thread. So if you don't mind scrolling manually, I think everything else will just work. Did you try it? I did try it and your description does not match my experience. Here's what I tried: I visited https://sqlite.org/forum which redirected me to https://sqlite.org/forum/forummain and there I see a list of "Most recent threads" with a table of (I assume) recent threads and text at the bottom telling me how long it took to generate that page. But every link in that table which would (again I assume) point to a page with that thread's text instead points to https://sqlite.org/forum/honeypot . Visiting https://sqlite.org/forum/honeypot returns a 1-paragraph page which says "Please enable javascript or log in to see this content". Hence I don't get to read the threads from the thread table. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] New SQLite Forum requires Javascript?
Richard Hipp wrote: The Forum is powered by Fossil. It has been in active use in the Fossil community for a couple of years, and has worked well. Is there a way to use this without running the Javascript? ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite.org website is now HTTPS-only
George wrote: Why can't we have both? I mean the software is in the public domain there is nothing to hide so what's the point of encrypting the site? ISPs and other intermediaries alter website traffic between the server and the client. The purpose of their alterations is irrelevant, you should get the data the server is trying to send you. You can never be sure if what you're getting is what the server tried to send you if you're getting that data over HTTP instead of HTTPS. Also, spying on the connection is trivial when data is exchanged in the clear. Other parties really don't need to know what you're requesting from or sending to a website. The software's lack of copyright really doesn't enter into any of this. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Mozilla wiki 'avoid SQLite'
Jean Chevalier wrote: > Somewhat contradictory the Mozilla Foundation being a member of the > SQLite Consortium while their performance wiki prominently features a > warning to developers against using SQLite allegedly for performance > reasons. Guard me from my friends... > > http://wiki.mozilla.org/Performance/Avoid_SQLite_In_Your_Next_Firefox_Feature That page describes situations where SQLite doesn't give best available performance, reduce complexity, or provide needed features, and then goes on to justify those conclusions (including recognizing how SQLite isn't unique in these respects: "This isn't an indictment of SQLite itself -- any other relational embedded DB would pose the same challenges."). I'm not sure what point you were raising in your post, so I'll have to guess. Your summary suggests that you expected SQLite Consortium members will endorse SQLite even in situations where SQLite isn't a good fit due to preferring other tradeoffs. Are SQLite Consortium members somehow obliged to endorse SQLite for tasks even when other approaches present more desirable tradeoffs? If so, where is this obligation published?
