pidgin-devel — DO NOT USE. See https://pidgin.im/cgi-bin/mailman/listinfo/devel

Re: [Gaim-devel] [Gaim-commits] A quick poll about Gaim mailing list

[Chris S. <gai...@no...>]

Sean Egan wrote:
> On 2/4/07, Colin Barrett <ti...@la...> wrote:
>   
>> Suggesting people write rules to add the tags is IMO ridiculous. It is
>> the expected case -- the VAST majority of mailing lists include tags
>> and not seeing them probably causes confusion. Seems to me that the
>> status quo should not have to change to the whims of the vocal
>> minority in this case. If you don't want the tags, strip 'em.
>>     
>
> You assume it's a minority who doesn't want their subjects messed
> with. In fact, isn't the whole purpose behind this thread to *see*
> which is the minority? Mark hasn't shared the results of his poll
> since Friday, but even then "[gaim-commits]" subjects were winning
> with only the *slightest* majority (literally just one person). Since
> then, a lot of strong arguments have been made against commits
> headers, so that number could have dropped to under 50%.
>
> Want to show us an update, Mark?
>
> The other glaring problem with your argument, as well as the whole
> *notion* of putting this up to a vote (I'm still a bit wtf'ed about
> that) is that it attempt to reduce the question to binary, whereas it
> seems clear to me from reading this thread that the inconvenience
> suffered by those who don't want their mail tagged, exceeds the
> convenience gained by those who do want it. This is something not
> accounted for in a yes or no vote.
>   

And actually I've changed my mind - I wasn't paying attention to the
fact that it was gaim-commits that was being discussed -- I'm not even
subscribed :-) , but even if I was the extremely standard format of the
message subjects and totally consistent sender makes tagging rather
redundant.

chris

Re: [Gaim-devel] [Gaim-commits] A quick poll about Gaim mailing list

[Sean E. <sea...@gm...>]

On 2/4/07, Colin Barrett <ti...@la...> wrote:
> Suggesting people write rules to add the tags is IMO ridiculous. It is
> the expected case -- the VAST majority of mailing lists include tags
> and not seeing them probably causes confusion. Seems to me that the
> status quo should not have to change to the whims of the vocal
> minority in this case. If you don't want the tags, strip 'em.

You assume it's a minority who doesn't want their subjects messed
with. In fact, isn't the whole purpose behind this thread to *see*
which is the minority? Mark hasn't shared the results of his poll
since Friday, but even then "[gaim-commits]" subjects were winning
with only the *slightest* majority (literally just one person). Since
then, a lot of strong arguments have been made against commits
headers, so that number could have dropped to under 50%.

Want to show us an update, Mark?

The other glaring problem with your argument, as well as the whole
*notion* of putting this up to a vote (I'm still a bit wtf'ed about
that) is that it attempt to reduce the question to binary, whereas it
seems clear to me from reading this thread that the inconvenience
suffered by those who don't want their mail tagged, exceeds the
convenience gained by those who do want it. This is something not
accounted for in a yes or no vote.

-s.

Re: [Gaim-devel] libgaim development start guide?

[Adil <ad...@ya...>]

--- Christian Alis <ia...@gm...> wrote:
> 
> Can somebody please provide me some pointers on how I can learn to
> develop applications that use libgaim?  HACKING seems to be too old
> and the doxygen-generated docs are good references but don't provide a
> good overview on how things work.  I just want to know the big picture
> first before getting burrowed in the source code. :)
> 

Applications that use libgaim provide the appropriate functions to perform
the UI operations invoked by the core (libgaim). This is done by
populating the uiops structures (eg. GaimAccountUiOps, GaimBlistUiOps
etc.) and making them available to the core (by calling
gaim_accounts_set_ui_ops, gaim_blist_set_ui_ops etc.). The functions in
the uiops are triggered at specific events, eg. the buddylist-uiops are
used to update the buddy list when a new buddy is added, or removed, or
the status of a buddy is changed etc. The same happens for conversations,
logging etc.

While the uiops are sufficient for most of the ui operations, it's likely
that you will want to use the gaim-signals as well to fine-tune some
stuff.

libgaim uses the glib mainloop to do all the things. The application
wanting to use libgaim will [likely] have to do the same.

The application will first initialize the core (gaim_core_init), add
plugin-search paths, load the saved plugins, prefs etc. If you have the
source, I suggest you take a look at console/gntgaim.c:init_libgaim to get
an idea of what's required to setup libgaim for your application.

Sadrul

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Gaim-devel] libgaim development start guide?

[Mark D. <ma...@ki...>]

On Sun, 4 Feb 2007 11:11:41 +0800, Christian Alis wrote
> Hi!
> 
> Can somebody please provide me some pointers on how I can learn to
> develop applications that use libgaim?  HACKING seems to be too old
> and the doxygen-generated docs are good references but don't provide 
> a good overview on how things work.  I just want to know the big picture
> first before getting burrowed in the source code. :)

An excellent question!  How's this?

libgaim is intended to be the core of an IM program.  When using libgaim,
you'll basically be writing a UI for this core chunk of code.  So Gaim is
really just a GTK+ frontend to libgaim, Gaim-text is an ncurses frontend, and
Adium is a Cocoa frontend.

Your program provides the int main() function.  Your main function will call
gaim_core_init(), which initializes libgaim.  Your main function will also
register a whole bunch of "callback" functions that are called by libgaim any
time there is something to tell the user.  For example, when libgaim receives
an IM it'll call your function for handling an incoming IM.  When one of your
buddies signs online libgaim will call your function to update the buddylist.

If your user fetches someones info then you'll call a libgaim function that
sends the appropriate message across the network.  Then libgaim will get a
response and call your function for handling buddy info.

Is that helpful?  Too detailed?  Not detailed enough?  Your feedback is
important, because at some point we'll be putting some of this info online.

-Mark

Re: [Gaim-devel] [Gaim-commits] A quick poll about Gaim mailing list

[Richard L. <rl...@wi...>]

On Sun, 2007-02-04 at 13:05 -0500, Ethan Blanton wrote:
> 1) The sender should not receive two copies, as both copies of the
> message will have the same Message-Id.  Many systems perform this
> de-duplication automatically, but for those which do not (it sounds
> like yours may not), you may find the following procmail recipe useful:

I should also note that I've done this in a workaround sort of way with
dumb mail clients for years. It takes a little more work, but that's a
trade-off of using a bad mail client (which I use for other reasons).

Also, Mailman offers the option to not send you a message via the list
if you were also in the To: or CC: line. You should go turn this option
on if you 1) don't want duplicates and 2) can't do it locally for some
reason. This does have the disadvantage that I could list you in the To:
or CC: but NOT actually list you as a RCPT with the SMTP server, so you
wouldn't get the message at all. However, without someone being
deliberately malicious, that's not going to happen, and everyone else on
the list will see it (including the archives).

I used to think Reply-To munging and Subject tagging were good ideas.
They're not.

Richard

Re: [Gaim-devel] [Gaim-commits] A quick poll about Gaim mailing list

[Ethan B. <ebl...@cs...>]

John Bailey spake unto us the following wisdom:
> What I would advocate a change in, though, is something I'm sure I will be
> berated for--the default reply address.  I don't particularly care if som=
eone is
> on the list or not; if I want to use e-mail to converse with a specific p=
erson
> on a mailing list subject, I can do that directly.  What I do care about,
> however, is that the mailing list receives my reply.  The default behavio=
r of
> replying to the sender is irritating at best, and I won't delve any deepe=
r into
> my personal opinion than is strictly necessary here.  The "Reply All" sol=
ution
> is suboptimal for two reasons--either 1) sender and list both receive cop=
y,
> which in my case guarantees I needlessly receive two copies of the same m=
essage;
> or 2) manual intervention is required *every* time to ensure that only th=
e list
> receives the reply, as I just did.

1) The sender should not receive two copies, as both copies of the
message will have the same Message-Id.  Many systems perform this
de-duplication automatically, but for those which do not (it sounds
like yours may not), you may find the following procmail recipe useful:

:0hW: msgid.lock
*^Message-Id:
| formail -D 8192 msgid.cache

2) Many mail clients, when informed of the presence of a mailing list,
offer a reply-to-list feature; for example, by default, this is bound
to 'L' in mutt (if my fingers remember correctly).  My mailreader
offers reply-to-sender, reply-to-list, and reply-to-all as distinct
features.  The only time I need to edit To/Cc lines manually is when I
wish to reply to some (computationally) arbitrary subset of the
current recipients, or when a message is sent to more than one mailing
list to which I am subscribed (requiring some disambiguation).

You might look to see if your mailer also has some similar feature.

The point of the reply-to document URL which has been floating around
this thread is that the Reply-To: header breaks the above
functionality; the reply-to header was created for a specific purpose,
and as such cannot just be arbitrarily ignored by an email client.
This means that, when abused by a mailing list, the above
reply-to-sender feature which my mailreader supports is reduced to
reply-to-list, removing one useful option from my tools.

This, as the subject line debate, comes down to good tools -- those
who have poor tools wish to force suboptimal behavior upon those who
have better tools, because they do not understand the tradeoffs
involved and are not concerned about others.

Ethan

--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764

Re: [Gaim-devel] [Gaim-commits] A quick poll about Gaim mailing list

[John B. <rek...@re...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Laager wrote:
> And, even though I use the tags right now due to the horrible
> server-side filtering implementation, I find them annoying. Look at this
> thread, for example. We've got both [Gaim-devel] and [Gaim-commits].
> What a waste of space!

As I mention below, the tags aren't an issue I have an opinion on.  I will,
however, agree that replies from one list to another needlessly waste a lot of
subject line space for no benefit at all.

> And in any case, I highly doubt that there are people who 1) develop
> Gaim, 2) subscribe to gaim-commits, 3) need to be subscribed to
> gaim-commits for development reasons, 4) have a bad mail reader, 5)
> refuse to switch mail readers or work around the loss of subject tags in
> some other way, and 6) would stop subscribing to gaim-commits because of
> that, AND 7) stop developing on Gaim because they're no longer
> subscribed to gaim-commits.
> 
> Richard

If nothing else, I agree with this statement whole-heartedly.  Personally I
don't particularly care either way on the tags issue.  I, too, use a GUI mail
client (Icedove, to be specific), and currently I am filtering based on the
tags.  It is, however, trivial for me to modify my filters appropriately to deal
with the subjects without tags.  Modifying these filters would also prevent the
occasional false positive I have seen in the past when someone replies to a
gaim-commits message and it lands here on the development list.  I should have
done this ages ago, but I am inherently lazy and change working things only when
I have to or when I am irritated by their ugliness.

What I would advocate a change in, though, is something I'm sure I will be
berated for--the default reply address.  I don't particularly care if someone is
on the list or not; if I want to use e-mail to converse with a specific person
on a mailing list subject, I can do that directly.  What I do care about,
however, is that the mailing list receives my reply.  The default behavior of
replying to the sender is irritating at best, and I won't delve any deeper into
my personal opinion than is strictly necessary here.  The "Reply All" solution
is suboptimal for two reasons--either 1) sender and list both receive copy,
which in my case guarantees I needlessly receive two copies of the same message;
or 2) manual intervention is required *every* time to ensure that only the list
receives the reply, as I just did.

John
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFxh1sBWJH/emdNtsRAhuVAJ92fZl/28SLw2sS60t2dq9ZqzZIrACfQpiI
jr+5kVCbV7ThWlUk5BLwz4c=
=WvEZ
-----END PGP SIGNATURE-----

Re: [Gaim-devel] [Gaim-commits] A quick poll about Gaim mailing list

[Stephen E. <spe...@gm...>]

On 2/4/07, Colin Barrett <ti...@la...> wrote:
> On Feb 3, 2007, at 4:56 AM, Chris Stafford wrote:
>
> > With tags I can do a sort visually and very quickly,
>
> I agree 100% here. I sort a number of mailing lists into a single
> directory ("Other Code"), due to it being dumb about subfolders. Tags
> help me visually sort messages.
>
> Suggesting people write rules to add the tags is IMO ridiculous. It is
> the expected case -- the VAST majority of mailing lists include tags
> and not seeing them probably causes confusion. Seems to me that the
> status quo should not have to change to the whims of the vocal
> minority in this case. If you don't want the tags, strip 'em.

The whole point of the links posted earlier is that stripping tags is
just useless work. If you want tags, why don't you add them yourself,
instead of having the client software add the tags, just to have them
stripped again later. Plus, stripping can never be done perfectly.

I voted for tags. Then I read the links and got convinced otherwise.
Really, it was just my own ignorance getting in the way.


Stephen

Re: [Gaim-devel] [Gaim-commits] A quick poll about Gaim mailing list

[David B. <Dav...@he...>]

From: gai...@li... on behalf of Sean Egan
On 2/2/07, Sean Egan <sea...@gm...> wrote:
> Becaues democracy only works with informed voters:
> http://www.andrew.cmu.edu/user/qralston/writing/tagging-harmful/

That might make totally no sense to the people on this list, which
brings up:  http://www.unicom.com/pw/reply-to-harmful.html :)

If you don't know what this is about, you can ignore it ;)

MY REPLY (stupid outlook....):
=20
And if you know, you can ignore it even more ;-)
=20
About the title, I alsothing that "Re: [Gaim-devel] [Gaim-commits] A =
quick poll about Gaim mailing list" is ... stupid.
=20
Regards,
David

Re: [Gaim-devel] Help on MSN mobile status

[Lee R. <phr...@gm...>]

Sean Egan wrote:
>  From my playing around, it looks like a user has to be online to get
>  his or her mobile number, and that we need the mobile number to send
>  a message to it. So if Gaim were to behave the way I described, it
>  would only be able to do so for people who were online at the same
>  time as I was, but then signed off. If you're offline for a month,
>  there's no way you're getting a message. Does this sound right?
>
>  If so, I'm favoring removing the "wireless" emblem from MSN at all,
>  as it certainly seems not to be any sort of actual 'status'

I'm not really a MSN user by any stretch of the imagination, but my cell 
phone (Windows Mobile 5.0 PocketPC) is just about always signed on, 
whether via GPRS, wifi, or USB+Activesync, so I figured I'd chip in my 
notes.

Microsoft has not (and likely will not) contract with my cellular 
provider to provide SMS-based MSN messaging. The official Windows Live 
Messenger (v 8.0.0812.00) always shows that user as mobile regardless of 
sign on order. And for reference, the official client shows does the 
following for mobile users: nothing different on the buddy list, banner 
message at top of IM window ("Messages you type here are delivered to a 
mobile phone or pager. The recipient may be charged for each message by 
his or her wireless service provider"), and hides the tab displaying 
buddy icons. Yet Gaim (revision 18175) shows no mobile emblem for this 
user, and I can't "Send to mobile" within Gaim (or any other client) 
because of the lack of SMS transport agreement.

I disagree with removing the mobile emblem for MSN on the basis that 
someday (after MSNp13 is merged?) Gaim will show said emblem for my 
non-MSN-over-SMS cell phone. Of course, if you're talking about removing 
a different component that wouldn't effect my scenario at all, you can 
ignore my ramblings.

--Lee

Re: [Gaim-devel] [Gaim-commits] A quick poll about Gaim mailing list

[Colin B. <ti...@la...>]

On Feb 3, 2007, at 4:56 AM, Chris Stafford wrote:

> With tags I can do a sort visually and very quickly,

I agree 100% here. I sort a number of mailing lists into a single  
directory ("Other Code"), due to it being dumb about subfolders. Tags  
help me visually sort messages.

Suggesting people write rules to add the tags is IMO ridiculous. It is  
the expected case -- the VAST majority of mailing lists include tags  
and not seeing them probably causes confusion. Seems to me that the  
status quo should not have to change to the whims of the vocal  
minority in this case. If you don't want the tags, strip 'em.

-Colin

Re: [Gaim-devel] Help on MSN mobile status

[Sean E. <sea...@gm...>]

>From my playing around, it looks like a user has to be online to get
his or her mobile number, and that we need the mobile number to send a
message to it. So if Gaim were to behave the way I described, it would
only be able to do so for people who were online at the same time as I
was, but then signed off. If you're offline for a month, there's no
way you're getting a message. Does this sound right?

If so, I'm favoring removing the "wireless" emblem from MSN at all, as
it certainly seems not to be any sort of actual 'status'

-s.

Re: [Gaim-devel] [ gaim-Bugs-1636195 ] Make Gaim use freedesktop.org basedir specification

[Richard L. <rl...@wi...>]

Let me ask you this... What's the big advantage to following the
freedesktop.org spec? How does it help you?

Richard

Re: [Gaim-devel] [ gaim-Bugs-1636195 ] Make Gaim use freedesktop.org basedir specification

[Martin O. <pah...@gm...>]

At first, nobody should call me an sync expert, Only things I've
"synchronized" this far are logs and  accounts.xml (mainly because users are
stored at IM servers and there is no problem for me to group them)...


On 2/4/07, Richard Laager <rl...@wi...> wrote:
>
>
> I don't think we really need a library to find "~/.cache". ;)


OK I agree. Still only as long, as long as that ~/.cache for example gets
reached through $XDG_CACHE_HOME variable, etc...

There will still be gaim specific sub-directory under that base, right?

A variable for all the config files sure could help ones not happy with the
way $HOME gets written currently. All that only when every other
freedesktop.org compatible application will use them the same way...

About windows the places could be something like %userprofile%\Application
Data\.config, %userprofile%\Application Data\.data and considering TEMP to
be user specific on the NT systems, then %TEMP%\.cache
Also there does exist the "All Users" folder in case machine wide settings
would ever be needed.

-- 
Martin
expressing his humble opinion only...

Re: [Gaim-devel] Help on MSN mobile status

[Richard L. <rl...@wi...>]

On Sat, 2007-02-03 at 20:35 -0800, Sean Egan wrote:
> Right, but that's because that's the way the AIM protocol and client
> handles it. I wouldn't want Gaim to do something weird and unexpected
> for MSN users.

As far as I recall, you don't do anything special in MSN on Windows to
send mobile messages. I believe it just shows a little banner in the
conversation window that it's going to their mobile device.

Richard

Re: [Gaim-devel] Help on MSN mobile status

[Sean E. <sea...@gm...>]

On 2/3/07, Kevin M Stange <ke...@si...> wrote:
> This is how AIM handles it, I believe.  Having the functionality
> consistent between protocols sounds likes a plus to me.

Right, but that's because that's the way the AIM protocol and client
handles it. I wouldn't want Gaim to do something weird and unexpected
for MSN users.

-s.

Re: [Gaim-devel] Help on MSN mobile status

[Kevin M S. <ke...@si...>]

Richard Laager wrote:
> On Sat, 2007-02-03 at 19:04 -0800, Sean Egan wrote:
>> It seems like, when the person is online, we should not ever show the
>> mobile icon. Then, when that person signs off, we continue to show
>> them as online, with the mobile icon, and send any IMs to that person
>> to his mobile device.
>=20
> Perfection!
>=20

This is how AIM handles it, I believe.  Having the functionality
consistent between protocols sounds likes a plus to me.

Kevin

Re: [Gaim-devel] [ gaim-Bugs-1636195 ] Make Gaim use freedesktop.org basedir specification

[Richard L. <rl...@wi...>]

On Sun, 2007-02-04 at 05:47 +0200, Martin Ott wrote:
> What else to sync besides user logs, accounts  and maybe the buddy
> list (even among buddy-icons - haven't tried that so far by myself)?
> They could at most get divided into two directories then: accounts as
> config; buddy list (among buddy icons) and log as data.=20

You need to sync blist.xml, account.xml, and logs at a minimum. The
icons can probably be re-retrieved. However, since we track them in
blist.xml, we'd have to make sure we deal with the situation
appropriately when the files disappear.

But instead of syncing .gaim, you'd have to sync multiple directories.
This isn't hard if you're an rsync expert, but I don't want to add
complexity for non-experts.

> Could Gaim have other than User specific config- and data files (as
> the freedesktop.org classification states)??

> In that case, certainly it would be better by the freedesktop.org
> itself to consider suggesting some common library for all
> freedesktop.org compatible software to reach those directories...

I don't think we really need a library to find "~/.cache". ;)

Richard

Re: [Gaim-devel] Help on MSN mobile status

[Richard L. <rl...@wi...>]

On Sat, 2007-02-03 at 19:04 -0800, Sean Egan wrote:
> Does this all sound like an accurate description?

Yes.

> If so, is that the
> way it *should* behave?

No.

> Is it important to the have the cell phone
> icon there? I'm trying to change Gaim to show the cell phone icon only
> when sending a message to that person will result in it going to a
> mobile device.

I like.

> It seems like, when the person is online, we should not ever show the
> mobile icon. Then, when that person signs off, we continue to show
> them as online, with the mobile icon, and send any IMs to that person
> to his mobile device.

Perfection!

> Can an MSN user respond to an SMS sent this way?

Yes, at least in some cases.

Richard

Re: [Gaim-devel] [ gaim-Bugs-1636195 ] Make Gaim use freedesktop.org basedir specification

[Martin O. <pah...@gm...>]

On 1/31/07, Richard Laager <rl...@wi...> wrote:
>
> I don't like this. It makes it harder to synchronize ~/.gaim between
> computers (which is more of an issue for Gaim than many other
> applications). It also doesn't map well to our win32 port.


What else to sync besides user logs, accounts  and maybe the buddy list
(even among buddy-icons - haven't tried that so far by myself)?
They could at most get divided into two directories then: accounts as
config; buddy list (among buddy icons) and log as data.

Could Gaim have other than User specific config- and data files (as the
freedesktop.org classification states)??

By win32 it would be quite nice, if all freedesktop.org compatible software
could hold its config- and data files inside some [freedesktop-config] and
[freedesktop-data] directories respectively under the one
[application-data-of-user]. Even machine specific settings could find their
place somewhere under the "All Users" folder of windows (like for example
the start menu has).

In that case, certainly it would be better by the freedesktop.org itself to
consider suggesting some common library for all freedesktop.org compatible
software to reach those directories... This library could be done and
suggested by developers of Gaim even and inside the very GTK both Gimp and
Gaim are using. :-)


-- 
Martin
Slept too early today...

[Gaim-devel] libgaim development start guide?

[Christian A. <ia...@gm...>]

Hi!

Can somebody please provide me some pointers on how I can learn to
develop applications that use libgaim?  HACKING seems to be too old
and the doxygen-generated docs are good references but don't provide a
good overview on how things work.  I just want to know the big picture
first before getting burrowed in the source code. :)

[Gaim-devel] Help on MSN mobile status

[Sean E. <sea...@gm...>]

I'm not an MSN user, really. Nor is anyone I know. I'm trying to
better integrate mobile status with our new status API.

We currently overlay a cell phone icon on an MSN user in some cases.
When I try signing onto MSN on my cell phone, that icon does not come
up. When, from Gaim, I turn on "Send to mobile," that icon does come
up, but the status is still tied to Gaim. I can be offline and still
have that icon. Sending a message does nothing, but choosing "Send to
mobile" from the context menu sends me an SMS message.

Does this all sound like an accurate description? If so, is that the
way it *should* behave? Is it important to the have the cell phone
icon there? I'm trying to change Gaim to show the cell phone icon only
when sending a message to that person will result in it going to a
mobile device.

It seems like, when the person is online, we should not ever show the
mobile icon. Then, when that person signs off, we continue to show
them as online, with the mobile icon, and send any IMs to that person
to his mobile device.

Can an MSN user respond to an SMS sent this way?

-s.

Re: [Gaim-devel] [Gaim-commits] A quick poll about Gaim mailing list

[Richard L. <rl...@wi...>]

On Sat, 2007-02-03 at 17:22 -0500, Ethan Blanton wrote:
> As a point of reference, note that many mailreaders (at least, mutt,
> which I use) can sort or limit mailboxes on the fly using simple
> patterns, so there is no "[writing] email rules" involved, here.  The
> bottom line is that many people weighing in on this issue either use
> massively insufficient email software, or can't be bothered to learn
> to use the features their email software provides.

I'm with Ethan all the way here. I use a GUI client that's suboptimal in
many ways, but it has no problems with filtering. I do have obviously
broken webmail. With it, I think I currently filter on the subject tags,
since they're there, but for other lists, I filter on the list address
in the To: or CC: and call it good enough, even though it may fail to
filter a message here or there. As soon as my provider gets better
webmail (which is my problem, as I'm the sysadmin there in charge of
that project), I'll be able to use correct filters and get a 100%
success rate.

And, even though I use the tags right now due to the horrible
server-side filtering implementation, I find them annoying. Look at this
thread, for example. We've got both [Gaim-devel] and [Gaim-commits].
What a waste of space!

And in any case, I highly doubt that there are people who 1) develop
Gaim, 2) subscribe to gaim-commits, 3) need to be subscribed to
gaim-commits for development reasons, 4) have a bad mail reader, 5)
refuse to switch mail readers or work around the loss of subject tags in
some other way, and 6) would stop subscribing to gaim-commits because of
that, AND 7) stop developing on Gaim because they're no longer
subscribed to gaim-commits.

Richard

Re: [Gaim-devel] [Gaim-commits] A quick poll about Gaim mailing list

[Ethan B. <ebl...@cs...>]

Chris Stafford spake unto us the following wisdom:
> With tags I can do a sort visually and very quickly, which will actually
> be based on the time I have available at that second rather than the way
> I felt when I wrote the rules (I only ever write email rules out of
> spite). I can even use the tags in webmail interfaces with no rules at
> all, which is pretty damn useful given the amount of time I spend in
> internet cafes. If you've got the access and inclination to use a
> rules-based system, write a rule to dump the tags. Simple.

As a point of reference, note that many mailreaders (at least, mutt,
which I use) can sort or limit mailboxes on the fly using simple
patterns, so there is no "[writing] email rules" involved, here.  The
bottom line is that many people weighing in on this issue either use
massively insufficient email software, or can't be bothered to learn
to use the features their email software provides.

Writing a rule to dump the tags is dealt with coherently in the link
that Sean posted.

Imagine the state of the world if *all* policies were decided based on
the lazy and ignorant, and the attitude that the competent would
figure out how to cope.

Ethan

--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764

Re: [Gaim-devel] [Gaim-commits] A quick poll about Gaim mailing list

[Ethan B. <ebl...@cs...>]

Luke Schierer spake unto us the following wisdom:
> In that its a common practice, even if a less than correct.  In that the
> argument you and Sean posted is wrong in at least one respect.

"Common practice" is *never* a good argument, when there is calculable
downside.  Many things are frighteningly common which are truly bad
ideas.  I am sure you can come up with an entire list.

In what respect is the argument wrong?  I read this email looking for
it, and didn't see anything.

> There are any number of people who could and would contribute useful and
> even correct patches to gaim, but who could be turned off by our holding
> to this practice, even though correct.  While yes this ignorance,
> willful or otherwise, is less than ideal, it is also beyond our ability
> to cure, at least to cure in every case.

There exist people who would fail to contribute to Gaim simply because
we decline to munge a subject header, on the grounds that any
mailreader worth using can flag mailing lists in a more intelligent
way?  I find that hard to believe, for one, and I'm not sure I want to
deal with such people, if they do exist, for two.

> Some of us are more concerned with finding the most pragmatic solution
> than with the technically most correct one.  The poll would help
> determine this.
>=20
> While I tend to be persuaded by the arguments that you and Sean have
> found and advanced, I really don't care.  I'm just as capable as using
> procmail to remove the tags as it is possible to use procmail to add
> them, if they did bother me, which they mostly don't.

The URL Sean posted addresses this.  Yes, I can de-munge mailing lists
in procmail; however, I shouldn't have to.

Personally, I find them *very* irritating, although I would not have
bothered to bring it up in the first place.  My mail index lists
'gaim-devel' *twice* due to those headers ... 10 characters plus 10
characters plus a few for brackets and spacing rapidly adds up to a
significant portion of an 80-column display.  I fail to see why I
should go out of my way to make my *good* software cope with
brokenness because other people have *bad* software.

I can see that logic, correctness, and reason have no place in this
argument, so I will cede to whatever the result is.  All I can say is,
it's a good thing you people don't get much email.  (Or, if you do,
it's a good thing you have enough free time to deal with it in such
obviously poor environments.)

Ethan

--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764