RE: [sqlite] DB managers that do searches?
On 31 Oct 2007 at 11:37, James Dennett wrote: > Bernie Cosell wrote: > > I guess you've never used a [good] GUI-driven DB > manager/administration > > pgm. > > Your guess (luckily for me) is very wrong. It's just that I call these > GUIs, not "DB managers". Ah... a terminology problem.. I'll just point out that the section in the wiki that has all of these pgms in it is called "Management Tools". > .. They're handy. I have a number of them > installed on the machine on which I write this, and I use them in > addition to command line tools. As I mentioned in another msg on this thread, we use phpMyAdmin for our MySQL databases at work and I can't remember the last time anyone at work needed (or wanted) to use the command line tool. Different strokes... > That's not a problem, is it? Just a question of using a tool at the > right level. If you want to automate things, writing code is often a > good way. If you want to do ad hoc work, a visual tool can be much more > convenient. Just so. Only difference between us here is that I have virtually no use for the command line tool: if I need to automate, I'll just write a little Perl/DBI pgm to do it (I have dozens of 'em..:o)) and I use the "visual tool" for everything else. I'd rather write a small Perl program that try to cobble up a script to be read into the command line app. As above, YMMV... > So you're looking for a graphical tool to allow you to manually view and > modify information in a SQLite3 database? Yes, and I'm now the happy user of sqliteman, so my search is over..:o). It's "query manager" does *exactly* what I needed and works wonderfully. (and indeed, easily found the index conflict I was trying to sort out easily.) /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] DB managers that do searches?
On 30 Oct 2007 at 23:31, Kees Nuyt wrote: > [Default] On Tue, 30 Oct 2007 16:57:55 -0400, "Bernie Cosell" > <[EMAIL PROTECTED]> wrote: > > >I'm trying to correct several little problems in a DB I have and I've > >now tried three [maybe four] freeware DB managers and not one includes > >a search function. I have a table with 800+ rows and I'd like to find > >particular records so I can edit them, and not having a search is > >proving to be a real hassle. [I've been spoiled, I guess, about > >phpMyAdmin..:o)] > > There is phpSQLiteAdmin. ...You also may find sqlite3explorer (my > favorite) useful. > See: > http://www.sqlite.org/cvstrac/wiki?p=ManagementTools > for those two and many others. Ah, I'd actually gone through the wiki list, but I didn't go all the way to the bottom to the "Inactive or Unsupported" ones. I've mostly struck out with the 'top' tools, so I'll give those a shot. Thanks!! /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] DB managers that do searches?
On 30 Oct 2007 at 14:05, James Dennett wrote: > > -Original Message- > > From: Bernie Cosell [mailto:[EMAIL PROTECTED] > > I'm trying to correct several little problems in a DB I have and I've > > now tried three [maybe four] freeware DB managers and not one includes > > a search function. > It would be very helpful if you'd define what you mean by "a search > function". What databases *do* is store and search Data; SQLite support > relational searches and full-text search, and other databases also allow > searching in various ways either for exact matches, LIKE clauses, > regexps, fuzzy search, natural language search, etc. I guess you've never used a [good] GUI-driven DB manager/administration pgm. The problem is that it is *hugely* easier to do a few clicks and "search" than to keep typing in 80-character SELECTs until you get the WHERE clause just-right, and then go back and edit the command to be an UPDATE (and don't mistype anything!). > I'm also wondering what you mean by a "DB manager" -- do you mean a > graphical user interface interfacing to an underlying database engine, > or something else? Yes. I'm not sure if you've had a chance to play with phpMyAdmin but it makes administering, taking care of, and tweaking MySQL DBs a real snap. The search function, for example, gives you a layout of the table and you can put in the search-values for the fields you care about and then you get a "minitable" of the search results [which are then easy to edit, delete, whatever]. /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] DB managers that do searches?
On 30 Oct 2007 at 14:27, Trevor Talbot wrote: > To help the conversation along a bit, phpMyAdmin is a web-based > administrative and design interface for MySQL. I don't use it so I > don't know exactly what kind of searching the OP is looking for > either, but at least we know the type of tool :) Just so -- I'm sorry about the confusion [I'd assumed, incorrectly, that my mention of phpMyAdmin would clarify what I was talking about]. Indeed: you can do *everything* from phpMyAdmin. Rename tables, add/delete columns, change column types [and names, of course], construct SQL statements graphically, etc, etc. The particular thing I was referring to was the search facility: you get a GUI presentation of the columns of the table and indicate which ones, and which search values, you care about and you get what we would call a 'view' of *just* those rows that match [so unlike from the command line, you don't even need to get a WHERE clause that matches _exactly_ -- if it just hits a few you just click the 'edit' icon on the one [or more] that you really care about]. I can't remember the last time I needed to do *anything* in terms of managing/editing/etc a MySQL database that required that I fire up the command line interface. /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] DB managers that do searches?
I'm trying to correct several little problems in a DB I have and I've now tried three [maybe four] freeware DB managers and not one includes a search function. I have a table with 800+ rows and I'd like to find particular records so I can edit them, and not having a search is proving to be a real hassle. [I've been spoiled, I guess, about phpMyAdmin..:o)] Is there a freeware manager for XP that includes searching capability? [If I were in long-term need of mgr stuff I'd happily buy one of them [they're inexpensive enough], but I"m just trying to correct typos in a DB that I recently converted to version 3] Thanks! /bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] Converting sqlite2 to sqlite3
I'm just restarting a long dormant project that uses SQLite [also converting it from being CGI-driven to being a self-contained Perl/Tk app]. I've discovered that my old database, which is likely sqlite2, won't open in the world of sqlite3 [duh!!]. I looked through the wiki and around the sqlite.org website and I hoped to find a 2->3 conversion tool, but I didn't see one. Any recommendations on how to effect the conversion. I see that there's a command-line tool for reading sqlite 2 DBs, so I guess I could do some sort of dump/export or something like that with that and then use an sqlite3 command line tool to import it. ??? Thanks! /bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Windows DB manager?
On 2 Jul 2006 at 3:04, Nemanja Corlija wrote: > On 7/1/06, Bernie Cosell <[EMAIL PROTECTED]> wrote: > > What's the current state of GUI-based managers for SQLite? I know there > > have been various admin apps for SQLite, but I've been out of touch and I > > didn't see any linked out of the sqlite.org web page. > > You can always find reasonably up-to-date list of SQLite GUIs, and > many other things, on SQLite wiki. > > http://www.sqlite.org/cvstrac/wiki?p=ManagementTools Ah, I figured that the info had to be *someplace* reasonable [on the web site], I just couldn't find it... it hadn't occurred to me that that kind of info would be in the wiki rather than on some kind of downloads/addons/etc link.. Duh! THANKS!! /bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <--
[sqlite] Windows DB manager?
What's the current state of GUI-based managers for SQLite? I know there have been various admin apps for SQLite, but I've been out of touch and I didn't see any linked out of the sqlite.org web page. Thanks! /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <--
Re: [sqlite] Hardcopy docs?
On 26 Jun 2006 at 14:14, [EMAIL PROTECTED] wrote: > "Bernie Cosell" <[EMAIL PROTECTED]> wrote: > > I'll confess that I am an old-fashioned "hardcopy" kind of guy... are the > > sqlite3 docs available in any sort of reasonably-printable format? > > > > http://www.apress.com/book/bookDisplay.html?bID=10130 Hmmm... Since I don't really need 450+ pages of info, but just something akin to a crib sheet of the SQL that sqlite supports (which I'd guess would end up at about 20 pages if it weren't so difficultly-embedded in html files), the option of a fifty dollar book isn't really very useful to me. [BTW: no knock on Mike or on the worth of the book. But: I'm not a beginner [either with Perl, SQL or SQLite] nor do I care hardly at all about SQLite's internals... I just need to know the SQL SQLite implements, and so virtually all of Mike's book is really not going to be of any interest or use to me... I'm just the wrong audience for it]. I guess I'll work harder at getting something readable out of the 'lang.html' pages... It looks like that if I cobble up a little script to take the pages linked out of lang.html and just delete the and blocks at the start of each page it'll get me just the reference info, and after that a pass through HTMLDOC and I suspect I'll have something more in line of what I was hoping for... I'll report back on how it goes in case anyone cares... tnx! /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <--
[sqlite] Hardcopy docs?
I'll confess that I am an old-fashioned "hardcopy" kind of guy... are the sqlite3 docs available in any sort of reasonably-printable format? /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <--
[sqlite] Subject: Re: [sqlite] atomic db replacement
On 21 Mar 2005 at 9:34, Ara.T.Howard wrote: > this is not always true - on nfs for example. the only atomic ops on nfs are > mkdir and symlink. And flock if the filesystem supports it [as ReiserFS does]. /bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <--
RE: [sqlite] long filenames on Mac OS
On 12 Apr 2004 at 11:56, Williams, Kenneth (Ken) (TLR Corp) wrote: > > -Original Message- > > From: Ralph Wetzel [mailto:[EMAIL PROTECTED] > > As only sqlite needs to know, how a journal is named, how about always > > truncating the original filename so that it fits (with the > > concetanated -j* ) into whatever length is ok for all > > supported systems? > > I'd prefer that it only did that on systems where filename length ... is a problem, i.e. that the max length is #define'd per-system. No ... need to penalize people whose OSs aren't so draconian. I don't understand -- why is whatever algorithm a program uses for generating a private temporary file a "penalty" no matter how the file name works out? Even "sqlite001", "sqlite002"...etc' would suffice for all I care; why do you care what name sqlite uses for its journal files? /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
On 7 Feb 2004 at 12:10, Rene wrote: > > How old is 2.5.6 version? > > july 7. 2002 > http://www.sqlite.org/cvstrac/timeline?d=3000&e=2004-Feb-07&c=0&px=&s=0&dm=1&dt=1&x=1&m=1 > > i'm just wondering what strategy will be if database format changes in the > future, do we depend on external utility then? I think the answer should be 'yes'. There are lots of ways you can move a DB from one engine to another, but if you have an 'orphaned' DB, then you're just out of luck, and we can't all have the luxury of storing a complete text-format data dump of our database around. I'm concerned about 'legacy' databases -- if/when the sysadmins update the SQLite package, all of my apps will die. But worse: some of my very infrequently used DBs [e.g., an archived log DB from past years] will become irretrievably dead. so I think, just as Word and Word Perfect and Excel and other such apps do, I really think that SQLite should have available 'helper' apps that'll be able to convert just about ANY old DB format to whatever-is- current. I agree, that the DB engine, itself, should *NOT* be larded up with all of that kind of stuff: keep it lean and mean. But *do* avoid orphaning our old data... /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Unix file locking is badly broken
On 11 Jan 2004 at 15:01, Mrs. Brisby wrote: > This works a lot more like the locks you're expecting, but as you're > probably already aware, flock() doesn't work over NFS. This is partially not true. Yes, flock() doesn't work over NFS to an ext2/3 filesystem, but at the least, but it works just fine to ReiserFS. Dunno its status to other FSs, but its not working is not an absolute, but rather a function of the being-NFS'ed-from FS [that is, the one running the NFSdaemon that is actually doing all the work]. Of course, knowing that doesn't make it useable for something like sqlite, where, indeed, flock *IS* broken for the default/near universal FS, and so SQLite could hardly depend on it working. /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] busy_timeout from the Perl DBD interface
On 2 Dec 2003 at 11:19, Matt Sergeant wrote: > On 1 Dec 2003, at 18:49, Bernie Cosell wrote: > > > Is it possible to set from Perl for SQLite to wait instead of die when > > it > > finds the database locked? > > > > We've been getting a few: > > [09:45:23] POP3< DBD::SQLite::db do failed: database is locked at ... > It's currently hard coded at 30 seconds (you can edit dbdimp.h to > change it if you want). Thanks for the info but I'm a bit confused -- Are you telling me that DBD::SQLite already does a 30-second-wait before giving you the 'locked' error? I guess it does [looking at dbdimp.c, I see the explicit, happens- every-time call to sqlite_busy_timout right there]. Sigh.. that means that there's a *serious* bug elsewhere in the code [since the DB shouldn't be locked for more than a fraction of a second at a time] Thanks.. now to go figure out what is REALLY wrong... /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sqlite] busy_timeout from the Perl DBD interface
Is it possible to set from Perl for SQLite to wait instead of die when it finds the database locked? We've been getting a few: [09:45:23] POP3< DBD::SQLite::db do failed: database is locked at ... and in double-checking the docs, I found: > When SQLite tries to access a file that is locked by another process, the > default behavior is to return SQLITE_BUSY. You can adjust this behavior > from C code using the sqlite_busy_handler() or sqlite_busy_timeout() API > functions. and I'm guessing that for my application, just setting busy_timeout to something like 30 seconds would do the job for me, but I'm not sure if/how that might be doable from DBD::SQLite in Perl. Thanks! /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sqlite] Postscript on double-emails
Bert and I have exchanged emails on this privately and the resolution is that he actually *WAS* subscribed twice to the list. And so in an odd way, everyone was correct: he *was* getting two copies of everything, but the listserver was not misconfigured or misbehaving. I'll re-extend my original offer: if you believe you're getting two copies of postings to the list, forward me the headers [all of them] for two "matching" messages you received and I'll be happy to try to help sort out what's going on... /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] double email
On 22 Nov 2003 at 22:23, Bert Verhees wrote: > > It seems to me that all the people send theiur ewmail double, and that it > > is a failure in the list software configuration. > > > > This email has only one TO: sqlite-users <[EMAIL PROTECTED]> > > And no CC or BCC, thus, if this is posted twice, it is the list software > > > > Only one conclusion, the list software is configured wrong. It is annoying > because I am reading from small bandwith and high price for this moment Wrong conclusion! I only received *ONE* copy of the message, so whatever is happening is specific to you. It is possible that *YOUR* appearance on the list is configured incorrectly, or that you are on the list twice or who knows what, but it is *NOT* a global problem [or if it is, it is somehow not affecting me]. Can you copy out the headers [*all* of them] from the two copies you received? Rather than bothering the entire list, you can just email them to me privately, if you'd prefer, and if there's something of list- interest in the resolution I'll email back the conclusion. /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] (Fwd) Re: [sqlite] Testing the new SQLite mailing list
On 20 Oct 2003 at 17:52, Bert Verhees wrote: > Bernie Cosell wrote: > >As I said, it is a *LONGSTANDING* debate that has been discussed for > >*YEARS* (decades!) off and on, here and there. And as I said, the > >general way it works out is that newcomers to the Internet usually like > >"reply-to-list" while the folks with more experience generally prefer > >"don't mess with the reply-to". ... > > > >Did you follow the URL in my post? > > > > <http://www.halisp.net/halisp/reply-to-harmful.html> > > > No, I do not have time for reading all kinds of links. At least we know some of the reasons for your not "understanding" the issues involved [as per your previous note]. A different view is that if you don't have time to really consider the problem and learn something about it, perhaps you shouldn't espouse such a strong opinion on it. It isn't like a new issue and that you're nearly the very first person to make the observation about 'reply-to'. > I am just trying to comfort people which are using very regular MUA's > (emailclients), and which are interested in SQLite and maybe less in all > kind of longstanding debates only interesting for grey haired oldies > which call everybody who is using the Internet less then ten years a > newcomer. Better to 'comfort', I guess, than presume that over the thirty years that folks have been doing email others have already pondered some of these issues and that folk might actually try to learn from their experience and advice. sigh -- > I thought, this mailing list was about SQLite and communicating about it. > This discussion about longlasting debates is really not very interesting > to me, nor to most people, most people want to have easy acces to a > mailinglist, Just so -- that's why some of us have just suggested that the list be set up using the 'best practices' that have been honed over the [many] years and be done with it. I believe it was *YOU* who were banging this drum, rather than just leaving the issue alone. > OK, let's vote, there is no other way. Not true: this isn't a democracy. This is Dr. Hipp's list and he can run it as he pleases... /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] (Fwd) Re: [sqlite] Testing the new SQLite mailing list
> Bernie Cosell wrote: > > >Note two things: first the verbiage about the 'teleconferencing' stuff > >has been removed [NB: I don't believe this is just an oversight, but > >rather because of a general feeling that "reply-to-list" is not such a > >good thing, as has been beaten to death here and elsewhere]. Second, in > >the use of reply-to the operative verb is "suggests", which clearly > >implies that mail clients that permit reply-addressing options *beyond* > >just "send it where the reply-to says" are proper and expected. > > > What do you mean with "beaten to death elsewhere" and "general feeling"?. As I said, it is a *LONGSTANDING* debate that has been discussed for *YEARS* (decades!) off and on, here and there. And as I said, the general way it works out is that newcomers to the Internet usually like "reply-to-list" while the folks with more experience generally prefer "don't mess with the reply-to". [and so there's a sort-of-common progression: the folk arguing for reply-to-list two years ago are now more impassive about it, while the folk that were arguing for reply-to- list five years ago generally realize that the prevailing wisdom on it was probably correct] It isn't a slam-dunk, black-and-white issue, of course -- there ARE arguments to be made on both sides [and they ARE made, over and over and over], but overall the general-wisdom on this is to leave the reply-to alone. Did you follow the URL in my post? <http://www.halisp.net/halisp/reply-to-harmful.html> And did you notice the date on it -- *1996*. And it was an old/tired issue *THEN*. *That's* what I meant by longstanding. And read the "Addendum": > In case you are wondering, yes, I once thought Reply-To munging was a > nifty idea. I got better though. Notice the progression: just as I mentioned in my paragraph above... it isn't unusual to start generally thinking "Reply-To munging was a nifty idea" but eventually, and with more experience, most folk change their view on this. > Every list to which I am subscribed uses the "reply-to"header to mark > the address of the list. Then you're not subscribed to very many lists and/or haven't been at this game very long... > Every MUA I use, which are Mozilla, Mutt, Pegasus offer the reply-to > address as first choice to send a reply to. Just so -- what's your point? *SOME* choice had to be first, and making it be reply-to is probably correct [given the RFC's recommendation]. so some times you pick the first choice and some times you pick the second [or third] choice... Now that we have "LIst-Id" headers, if you had a smart enough email client, you'd actually have both "reply" and "followup" functions [which would *ONLY* work properly if the MLM doesn't fool with reply-to... yet another reason why messing with reply-to is a bad idea: it cripples one neat [RFC-supported] function of the really- competent MUAs] > And as you state yourself, RFC 2822 explicitely allows the use of the > reply-to header. Just so -- again, what's your point? No one has said it is *not*allowed* for the MLM to change the reply-to, only that, on balance, it is better left alone. > I really do not understand why sqlite should act different than all > mailinglists I get mail from. Perhaps because sqlite is more sensibly set up?? Is your 'understanding' based on your actually reviewing any/some of the thinking and arguments on this matter that have been made over the years/decades? > And I do not see the problem, if the reply-to header is used, all other > headers can stay the same, but many people are helped with this. As has been pointed out [both here and in the MANY discussions on this matter], *SOME* people are helped with it, but overall the consensus is generally that it hurts more than it helps. /bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] (Fwd) Re: [sqlite] Testing the new SQLite mailing list
On 18 Oct 2003 at 17:59, [EMAIL PROTECTED] wrote: > > [...] > > The mailing list software ALREADY works according to RFC 822. Go back, > > re-read the sentence you just posted and note that the emphasis belongs > > on the word "reply" not on "super-sedes" [sic]. > > You are right, I cited the wrong sentence, this one is better, also from RFC 822 > > 4.4.3. REPLY-TO / RESENT-REPLY-TO Note that debating the contents of RFC 822 is beside the point. It has been superceded by RFC 2822 and it has no such section -- the info about that field has been trimmed down substantially. > 3.6.2. Originator fields > >The originator fields of a message consist of the from field, the >sender field (when applicable), and optionally the reply-to field. >... an optional >reply-to field MAY also be included, which contains the field name >"Reply-To" and a comma-separated list of one or more addresses. [...] >The originator fields also provide the information required when >replying to a message. When the "Reply-To:" field is present, it >indicates the mailbox(es) to which the author of the message suggests >that replies be sent. In the absence of the "Reply-To:" field, replies >SHOULD by default be sent to the mailbox(es) specified in the "From:" >field unless otherwise specified by the person composing the reply. Note two things: first the verbiage about the 'teleconferencing' stuff has been removed [NB: I don't believe this is just an oversight, but rather because of a general feeling that "reply-to-list" is not such a good thing, as has been beaten to death here and elsewhere]. Second, in the use of reply-to the operative verb is "suggests", which clearly implies that mail clients that permit reply-addressing options *beyond* just "send it where the reply-to says" are proper and expected. /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Testing the new SQLite mailing list
On 16 Oct 2003 at 17:08, Paul Smith wrote: > At 16:44 16/10/2003, you wrote: > >I prefer the 'reply to sender' default rather than > >'reply to all'. ... > It really depends what you see the purpose of the list being. > > If replies only go back to the original message sender, then there are > quite a few disadvantages: The problem with this is that it presumes [by your use of 'only'] that the list membership is either entirely [or primarily] made of folk who cannot manage to do anything fancier/cleverer with their email clients than hit "reply". now, if you had said that "..._some_ replies will go back ...unintentionally..." that'd be closer to the fact, I think... And look at the other side of the coin -- if you send a reply privately that you intended to send publicly, that is an easy oversight to correct [in a large variety of ways], and generally little/no harm done (either to the parties involved or to the forum). The converse is not true: if you send a reply publicly that you really intended to keep private that's an unfixable faux pas. I also note that for most mail clients, it is easiier to make a *choice* [for those of us who do make such choices] if the list is reply-to-sender. For most [but not all!] mail clients, it is VERY much harder [near impossible for some if you don't type in the address brute-force by hand into the reply!] to address a private reply if the list is set up reply-to-list. /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Testing the new SQLite mailing list
On 16 Oct 2003 at 11:03, D. Richard Hipp wrote: > > 9.8 Setting ``Reply-To: list at host''. > > This is not recommended, since it leads to dissemination via the list of > > messages returned from bad auto-responders and MTAs. Also, it may lead to > > public replies to the list where personal replies were intended. In > > addition, the original ``Reply-To:'' header is lost. ... > > So now I'm thinking I should follow this advice and leave the > Reply-To: header as it is. Thoughts anyone? This is a longstanding debate. Most more-experienced net-folk prefer reply-to- author, newer-net-folk seem to lean toward reply-to-list [not absolute either way of course, just the general tendency]. I'm solidly in the reply-to-author camp. More here: <http://www.unicom.com/pw/reply-to-harmful.html> /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
