In <slrnffffrm...@dost.mchm.siemens.de>, Thomas Wiegner wrote:
> On 2007–09—24, Thomas Wiegner <wie...@gmx.de> wrote:
>> Useless use of multipart postings is something which does *not*
>> improve the usenet.
How thoroughly embarrassing.
>> I'm pretty sure it is possible to turn off this braindead default
>> behaviour of alpine (I know it's possible for pain^Wpine)
It appears that in my quoting of a message that used charset=big5, alpine
decided to package my entire message as the only part of MULTIPART/MIXED
message.
(Al)pine's default behavior, as far as I know, has always been to use
text/plain without creating a multipart message.
> UPS, this should have been a reply to
> <alpine.OSX.0.9999...@hagrid.ewd.goldmark.org>
That really is odd looking. I don't understand why alpine would want to
create a single part, "multipart" message.
> Anyway, good you changed this.
I did nothing. Apparently it has to do with what kind of stuff I'm
quoting. As I'm sure you've noticed, this message that you are reading
right now is an offender as well. I think that date in your own reply
lead-in is what triggered it in this instance, but I don't why alpine
behaves this way.
Thanks for letting me know about this.
-j
--
Jeffrey Goldberg http://www.goldmark.org/jeff/
I rarely read top-posted, over-quoting or HTML postings.
http://improve-usenet.org/
:) > > I'm pretty sure it is possible to turn off this braindead default
:) > > behaviour of alpine (I know it's possible for pain^Wpine)
:)
:) It appears that in my quoting of a message that used charset=big5,
:) alpine decided to package my entire message as the only part of
:) MULTIPART/MIXED message.
:)
:) (Al)pine's default behavior, as far as I know, has always been to use
:) text/plain without creating a multipart message.
There is a feature in Pine which controls this. It is disabled in this
case in your configuration. Its help text is below
(x-pine-help:h_downgrade_multipart_to_text). I hope this helps.
FEATURE: Downgrade-Multipart-To-Text
This feature affects Pine's behavior when sending mail. Internet standards
require Pine to translate all non-ASCII characters in messages that it
sends using MIME encoding. This encoding can be ostensibly broken for
recipients if any agent between Pine and the recipient, such as an email
list expander, appends text to the message, such as list information or
advertising. When sending such messages Pine attempts to protect such
encoding by placing extra MIME boundaries around the message text.
These extra boundaries are invisible to recipients that use MIME-aware
email programs (the vast majority). However, if you correspond with users
of email programs that are not MIME-aware, or do not handle the extra
boundaries gracefully, you can use this feature to prevent Pine from
including the extra MIME information. Of course, it will increase the
likelihood that non-ASCII text you send may appear corrupt to the
recipient.
--
Eduardo
http://staff.washington.edu/chappa/pine/
> There is a feature in Pine which controls this. It is disabled in this
> case in your configuration. Its help text is below
> (x-pine-help:h_downgrade_multipart_to_text). I hope this helps.
>
> FEATURE: Downgrade-Multipart-To-Text
>
> This feature affects Pine's behavior when sending mail. Internet standards
> require Pine to translate all non-ASCII characters in messages that it
> sends using MIME encoding. This encoding can be ostensibly broken for
> recipients if any agent between Pine and the recipient, such as an email
> list expander, appends text to the message, such as list information or
> advertising. When sending such messages Pine attempts to protect such
> encoding by placing extra MIME boundaries around the message text.
Eduardo,
That makes absolute sense for mail. (Al)pine's default before is the
correct choice for mail. The difficulty it seems is that there are a lot
of people using newsreaders that don't do MIME properly.
So I guess what I would want is a
"Downgrade-multipart-to-single-part-when-posting-to-news"
which seems like a lot to ask.
> There is a feature in Pine which controls this. It is disabled in this
> case in your configuration. Its help text is below
> (x-pine-help:h_downgrade_multipart_to_text). I hope this helps.
>
> FEATURE: Downgrade-Multipart-To-Text
>
> This feature affects Pine's behavior when sending mail. Internet standards
> require Pine to translate all non-ASCII characters in messages that it
> sends using MIME encoding. This encoding can be ostensibly broken for
> recipients if any agent between Pine and the recipient, such as an email
> list expander, appends text to the message, such as list information or
> advertising. When sending such messages Pine attempts to protect such
> encoding by placing extra MIME boundaries around the message text.
There has been no such added text in Jeffrey's posts.
> These extra boundaries are invisible to recipients that use MIME-aware
> email programs (the vast majority). However, if you correspond with users
> of email programs that are not MIME-aware, or do not handle the extra
> boundaries gracefully, you can use this feature to prevent Pine from
> including the extra MIME information. Of course, it will increase the
> likelihood that non-ASCII text you send may appear corrupt to the
> recipient.
I have no problem reading other MIME-encoded posts with slrn.
The problem is that multipart MIME posts are being sent when all
that's needed is a character-set declaration in the headers of a
*single-part* post.
I'll add this:
é
just to see what happens if a pine user replies to this. It would also
be interesting to know what users of other newsreaders are seeing in
the questionable posts, just in case it's really a bug in slrn.
It would be better to test this in a *.test group, but we'd all have
to agree to subscribe to the same one.
--
PJR :-)
> So I guess what I would want is a
>
> "Downgrade-multipart-to-single-part-when-posting-to-news"
>
> which seems like a lot to ask.
Unicode would be preferable, and one day perhaps all these legacy
character sets will die out and stop causing confusion. Does pine
support Unicode, e.g. UTF-8?
Most of your posts cause no problems at all; only the ones that used a
"Big-5" character set (in response to a post that included three
Chinese characters) were messed up.
By the way, is comp.mail.pine a proper place for discussion of pine
when it's used for Usenet, not for mail? I'm wondering, just in case
we get any pine questions in news.software.readers that could be
redirected to pine experts.
Once again, here's an "é". I want to know what happens.
--
PJR :-)
:) Eduardo,
:)
:) That makes absolute sense for mail. (Al)pine's default before is the
:) correct choice for mail. The difficulty it seems is that there are a
:) lot of people using newsreaders that don't do MIME properly.
:)
:) So I guess what I would want is a
:)
:) "Downgrade-multipart-to-single-part-when-posting-to-news"
:)
:) which seems like a lot to ask.
But consider that there could be a "free" news server out there that is
appending stuff (e.g. ads) to free posts and appends these messages
without regards to the charset of the message. Then wrapping makes sense.
I do not claim this is right or wrong. I only claim that this is the way
it works and why it works this way.
--
Eduardo
http://staff.washington.edu/chappa/pine/
:) I have no problem reading other MIME-encoded posts with slrn.
Well, you have found a case where you have a problem reading a
MIME-encoded message with slrn. The question is whose fault is it? lack of
support in slrn? over zealous behavior of Pine? Take your pick.
:) The problem is that multipart MIME posts are being sent when all that's
:) needed is a character-set declaration in the headers of a *single-part*
:) post.
Unless there is a news server that adds advertisement to every post
regardless of charset, then you are right.
In my opinion Pine's behavior is safer in terms of taking care of the
content of the message, but it might be unnecessary for news. I would
choose being cautious, though. I admit that I prefer a world where this
behavior is not necessary, but apparently we can not guarantee that we
live in such world. In fact, this "feature" (or bug, take your pick) came
as a response that the world we live in does not behave properly.
:) I'll add this:
:) é
:) just to see what happens if a pine user replies to this. It would also
:) be interesting to know what users of other newsreaders are seeing in
:) the questionable posts, just in case it's really a bug in slrn.
Your test should fail with my message. I have enabled that feature in
Pine, so my messages get downgraded automatically.
--
Eduardo
http://staff.washington.edu/chappa/pine/
> In news.software.readers on Mon, 24 Sep 2007 12:37:52 -0700, Eduardo
> Chappa <cha...@u.washington.edu> wrote:
>
>> There is a feature in Pine which controls this. It is disabled in this
>> case in your configuration. Its help text is below
>> (x-pine-help:h_downgrade_multipart_to_text). I hope this helps.
>>
>> FEATURE: Downgrade-Multipart-To-Text
>>
>> This feature affects Pine's behavior when sending mail. Internet standards
>> require Pine to translate all non-ASCII characters in messages that it
>> sends using MIME encoding. This encoding can be ostensibly broken for
>> recipients if any agent between Pine and the recipient, such as an email
>> list expander, appends text to the message, such as list information or
>> advertising. When sending such messages Pine attempts to protect such
>> encoding by placing extra MIME boundaries around the message text.
>
> There has been no such added text in Jeffrey's posts.
No, but when one sends to a mailing list text is added. (Al)pine doesn't
know what will happen to the message after it's sent it off. And because
things do occasionally get appended, it is the right decision to
encapsulate it in its own part.
> I have no problem reading other MIME-encoded posts with slrn.
Apparently slrn can deal with
content-type: text/plain; charset=whatever
just fine. But it is falling down on multipart/mixed, even when the
part(s) are things that it would otherwise be able to cope with. So slrn
is only partially MIME aware.
> The problem is that multipart MIME posts are being sent when all
> that's needed is a character-set declaration in the headers of a
> *single-part* post.
While that might always be safe for news to help out newsclients that
only do MIME halfway that won't generally work for mail for the reasons
quoted (which hadn't occurred to me until Eduardo posted that bit from the
documentation.
> I'll add this:
> é
> just to see what happens if a pine user replies to this.
From what I now understand of how alpine works, this will trigger the
multipart/mixed message.
> It would also
> be interesting to know what users of other newsreaders are seeing in
> the questionable posts, just in case it's really a bug in slrn.
Yes. But I fear that those who are experiencing the problem aren't going
to have the patience to read through the messages posted by (al)pine
users.
Cheers,
> Unicode would be preferable, and one day perhaps all these legacy
> character sets will die out and stop causing confusion. Does pine
> support Unicode, e.g. UTF-8?
Pine does. But that doesn't solve this problem. Until we know that
anything added to a message would be expecting to add to a UTF8 single
part, Pine (and other mailers) should behave as Pine does.
> Most of your posts cause no problems at all; only the ones that used a
> "Big-5" character set (in response to a post that included three
> Chinese characters) were messed up.
There was also a UTF8 message with non-ASCII characters I quoted that also
behaved this way.
> Once again, here's an [...]
I'm not quoting that this time because I do want people to be able to more
easily read my response to you.
I see from you (and still here in my editor) the same e with the mark
over it that I saw in Peter's orignal send. I don't know what you'll
see when I send *this*, but I'm using the same client he is although his
has different tweaks.
--
Blinky RLU 297263
Killing all posts from Google Groups
The Usenet Improvement Project moved to this site August 28th:
http://improve-usenet.org
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
>
> --0-1219551813-1190669052=:468
> Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: QUOTED-PRINTABLE
You're doing it again, and this time it's ordinary UTF-8 that's being
sent as multipart/mixed for no reason. Why can't pine just specify the
charset in the headers for the whole post, like other newsreaders?
I'm now satisfied that the bug is in pine, not in slrn.
--
PJR :-)
> On Mon, 24 Sep 2007, Peter J Ross wrote:
>
>:) I have no problem reading other MIME-encoded posts with slrn.
>
> Well, you have found a case where you have a problem reading a
> MIME-encoded message with slrn. The question is whose fault is it? lack of
> support in slrn? over zealous behavior of Pine? Take your pick.
Pine seems to be the only newsreader that sends non-ASCII posts as
multipart MIME messages.
To me, it's a bug. To you, it's a feature. *shrug*
<...>
> Your test should fail with my message. I have enabled that feature in
> Pine, so my messages get downgraded automatically.
Compliance with standard Usenet conventions isn't "downgrading".
--
PJR :-)
:) > This message is in MIME format. The first part should be readable
:) > text, while the remaining parts are likely unreadable without
:) > MIME-aware tools.
:) >
:) > --0-1219551813-1190669052=:468
:) > Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
:) > Content-Transfer-Encoding: QUOTED-PRINTABLE
:)
:) You're doing it again, and this time it's ordinary UTF-8 that's being
:) sent as multipart/mixed for no reason. Why can't pine just specify the
:) charset in the headers for the whole post, like other newsreaders?
Let me put it this way, maybe you will get it now.
Imagine I send you letters to your home. Normally I would just put them
in an envelope and you can just open it and read it at home as is normally
done. You do not have problems with that mail.
Assume that for whatever reason, I decided to send you a letter in a box
that requires a special kind of scissors for it to be opened. Scissors can
be found in any store.
Now if you do not have scissors at home, is it my fault that you can not
open the box where I put the letter? Of course you can be mad at me for
sending the letter in a box, but it is not my fault that you can not read
it; after all anyone with scissors can open the box.
You have to make a choice:
* Get the scissors and open the box
* Do not get scissors.
Of course in the future you can request, and even ignore all people that
send you letters in boxes, but that won't stop the world from using boxes,
so it's up to you.
The encoding of the message was done in a standard compliant way. Known
and practicesd for years already. If slrn does not support it, you may
want to request to anyone developing it that they add support to it,
because it seems to be that people exchange messages in that form, even if
you see no reason for it. If the feature gets added, great.
--
Eduardo
http://staff.washington.edu/chappa/pine/
> Let me put it this way, maybe you will get it now.
Let me put it this way:
"Content-Type: multipart/mixed" has no place in Usenet outside
alt.binaries, with the sole exception of PGP/MIME signatures, and even
they're generally disliked and are likely to result in the poster
being widely killfiled.
Please encourage the pine developers to fix the bug in their software
that prevents pine users from sending anything other than US-ASCII
without perpetrating an approximate equivalent to text/html.
--
PJR :-)
> Am I the only one who thinks that (a) pine is broken and (b) some
> comp.mail.pine posters are in danger of disappearing up their own
> arses?
The rational for (al)pine using multipart/mixed was explained in the
material Eduardo posted. Do you have an argument with that rationale?
If so, don't just bitch about it among yourselves, tell it to the pine
people.
> Pine is sending "multipart/mixed" articles, and they think that's
> *good*.
Apparently slrn only implements MIME standards in a half-assed way, and
they think that that is good. Furthermore those users want the rest of
the world to adjust slrn's non-standard implementation.
> (I've snecked the crosspost, because I'm talking about them, not to
> them.)
Ooops. I put it back in because now I'm talking about slrn users who like
to lecture others about standards and correctly say that people shouldn't
"break" their own software to adjust to others' non-standard
implementations. We like talking *about* such things on comp.mail.pine.
It does happen and it happens because the server allows it and people that
never heard of USENET are running the show. They look and see a way to get
some "free advertizing". Then they don't even know how to do it cleanly.
Top
The good news in all of this is that USENET is dying rapidly and in a few
years nobody will care. Many formerly-respectable newsgroups have become
sewers, with the result that many former participants have dropped out.
Our USENET servers will probably be shut down due to disuse (only a few
dozen people still read news) in the not-too-distant future. I read fewer
than 10 newsgroups these days.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
I saw something about a major state university turning off its servers a
month or two ago; I think it was in Virginia, but it might have been in
North Carolina -- I just have a vague memory of the general area.
That was sad; two is sadder yet.
> The good news in all of this is that USENET is dying rapidly and in a few
> years nobody will care.
How is that "good news"?
--
"Ubuntu" - an African word meaning "Slackware is too hard for me".
And why are only posts with non-ascii characters mangled to pseudo
multipart postings? The above argument is also valid for pure us-ascii
postings.
I've never seen newsservers adding ads to postings. I've seen that on
mailing lists.
Thomas
The reason is simply not true. It makes no sense to do what pine does,
to create "multipart" posts for articles with 8 bit characters and not
to do so for us-ascii. At least with the argument he said, why paine
does this.
The only reason why I could imagine to do this IMHO is that they did
implement a different behavior when talking to mailservers which are 8
bit aware or not.
The way pine is encoding mails it will never have a different
content-type in the header except from:
| Content-Type: text/plain; charset=us-ascii
And this has nothing to do with protecting Emails/News from ads. This
has to do with the old times when there where mailservers not accepting
8bit mails.
>> Pine is sending "multipart/mixed" articles, and they think that's
>> *good*.
>
> Apparently slrn only implements MIME standards in a half-assed way, and
> they think that that is good. Furthermore those users want the rest of
> the world to adjust slrn's non-standard implementation.
I agree, that at least the multipart handling of slrn is not so good. I
wrote a patch for slrn, that can ease the pain when reading pine
articels. Those guys here using my patch (included in pl2.1) should be
able to see the difference when adding
| set minimal_multipart 0
to the slrnrc.
But the thing is, usenet is a text only medium, there is no need for
multipart/mixed, except for binary groups. slrn focussed on the
important features of a newsreader, like threading, scoring etc.
Since when pine was able to to threading?
Cheers,
Thomas
--
slrn charset patches: http://www.foory.de/thw/slrn/
:) On 2007-09-24, Eduardo Chappa <cha...@u.washington.edu> wrote:
:) > On Mon, 24 Sep 2007, Jeffrey Goldberg wrote:
:) >
:) >:) That makes absolute sense for mail. (Al)pine's default before is
:) >:) the correct choice for mail. The difficulty it seems is that there
:) >:) are a lot of people using newsreaders that don't do MIME properly.
:) >:)
:) >:) So I guess what I would want is a
:) >:)
:) >:) "Downgrade-multipart-to-single-part-when-posting-to-news"
:) >:)
:) >:) which seems like a lot to ask.
:) >
:) > But consider that there could be a "free" news server out there that
:) > is appending stuff (e.g. ads) to free posts and appends these
:) > messages without regards to the charset of the message. Then wrapping
:) > makes sense.
:)
:) And why are only posts with non-ascii characters mangled to pseudo
:) multipart postings? The above argument is also valid for pure us-ascii
:) postings.
How? If a post contains only us-ascii, then that message is labeled as
such, and adding ascii to it won't do anything.
Now if you have a text encoded, and add ascii, then things get mangled,
and that's where the problem comes from.
:) I've never seen newsservers adding ads to postings. I've seen that on
:) mailing lists.
I said I don't know if it makes sense to do this for news. I said that
wrapping could be necessary in a situation like this. I do not know of any
news server that does what I told you, but I don't discard that behavior.
To me the behavior makes sense. It might be undesirable, but it's a
reality and improving slrn will make the "problem" go away.
--
Eduardo
http://staff.washington.edu/chappa/pine/
It's common, Thomas. I see it all the time -- three- or four-line
server ad sigs below what the poster has posted.
:) But the thing is, usenet is a text only medium, there is no need for
:) multipart/mixed, except for binary groups.
Aha!, that's your point. No wonder Mark is predicting the end of usenet. A
text only medium in this age? I hope Mark is starts advocating for a new
USENET++ based on IMAP ;). Then this argument wouldn't even make sense.
You see, I've never converted anyone to Pine, because despite Pine being a
wonderful program does not have a GUI. It's time to move to a new usenet,
one that follows the trends of the time.
:) slrn focussed on the important features of a newsreader, like
:) threading, scoring etc.
:)
:) Since when pine was able to to threading?
I understand, but USENET is not about threading or scoring. Threading and
scoring exists because users want to be able to read news more
conveniently, and programs like Pine support such features. Similarly,
MIME exists so that users can exchange information. Some people are being
hurt for the lack of a feature of a program and blame the people that
point that out to them for their grief. I am sure that slrn must be a very
good program. It just needs an update to deal with some already old
technology.
--
Eduardo
http://staff.washington.edu/chappa/pine/
> On Tue, 25 Sep 2007, Thomas Wiegner wrote:
>:) And why are only posts with non-ascii characters mangled to pseudo
>:) multipart postings? The above argument is also valid for pure us-ascii
>:) postings.
>
> How? If a post contains only us-ascii, then that message is labeled as
> such, and adding ascii to it won't do anything.
And what's know the difference if the post contains iso-8859-1 or
utf-8, then that message would be labeled as such, and adding ascii to
it won't do anything.
You see my point?
> Now if you have a text encoded, and add ascii, then things get mangled,
> and that's where the problem comes from.
No it does not, adding ascii won't do anything, because the plain ascii
characters are encoded in every encoding the same.
>:) I've never seen newsservers adding ads to postings. I've seen that on
>:) mailing lists.
>
> I said I don't know if it makes sense to do this for news. I said that
> wrapping could be necessary in a situation like this. I do not know of any
> news server that does what I told you, but I don't discard that behavior.
> To me the behavior makes sense.
Wrapping might make sense to protect messages, but it should not be the
default behaviour.
It was already the default behavior, when I used it 15 years back at the
university and at this time adding ads to postings or emails was
definitely *not* the problem.
This wrapping was done because of not 8 bit aware mailservers and it
seems to me the programmers did not want to implement the smtp dialog in
a way to figure out whether the mailserver was 8 bit capable or not.
> It might be undesirable, but it's a reality and improving slrn will
> make the "problem" go away.
Yes, in this point you are right, that's the reason, why I changed this
in slrn. With my patches slrn displays multipart mangled postings how
they should look.
Thomas
--
multipart support for slrn: http://www.foory.de/thw/slrn/
So the trend being to Google Groups and other klunky web gateways for
the incompetent, you're sending them there where they may not even know
they're *using* Usenet? No, I'm not suggesting that that's a good idea;
please see my sig for an indication of my stance on that.
On Tue, 25 Sep 2007, Peter J Ross wrote:
> Let me put it this way:
>
> "Content-Type: multipart/mixed" has no place in Usenet outside
> alt.binaries, with the sole exception of PGP/MIME signatures, and even
> they're generally disliked and are likely to result in the poster
> being widely killfiled.
>
> Please encourage the pine developers to fix the bug in their software
> that prevents pine users from sending anything other than US-ASCII
> without perpetrating an approximate equivalent to text/html.
So, if I put something like '£ € ¥ ⅟₁₆' here, this post becomes
multipart?
Or did I miss something?
Regards,
Rob
--
+----------------------------------------------------------------------+
| Rob van der Putten, r...@sput.nl |
| http://www.sput.nl/spam/spam-policy.html |
+----------------------------------------------------------------------+
Rob van der Putten wrote:
> So, if I put something like '£ € ¥ ⅟₁₆' here, this post becomes multipart?
> Or did I miss something?
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Message-ID: <alpine.DEB.0.9999....@sput.int.sput.nl>
Regards,
Rob
--
Terry Gilliam's Brazil is here and now
> Jeffrey Goldberg <nob...@goldmark.org> wrote:
>> The rational for (al)pine using multipart/mixed was explained in the
>> material Eduardo posted.
> The reason is simply not true. It makes no sense to do what pine does,
> to create "multipart" posts for articles with 8 bit characters and not
> to do so for us-ascii. At least with the argument he said, why paine
> does this.
I will leave this for others to discuss. My opinions on this are far from
solid. I assume that the pine people put that in to solve some real
problem. But what you say also makes sense.
> I agree, that at least the multipart handling of slrn is not so good. I
> wrote a patch for slrn, that can ease the pain when reading pine
> articels. Those guys here using my patch (included in pl2.1) should be
> able to see the difference when adding
>
> | set minimal_multipart 0
That is good news. I know nothing about the slrn development process, but
I hope that your patch becomes "official" and it seems that the setting
it introduces ought to be the default.
> But the thing is, usenet is a text only medium, there is no need for
> multipart/mixed, except for binary groups.
As you can imagine, Pine users also agree that usenet should be text only.
But the way for slrn to support that while still complying with MIME
standards is not to simply barf at multipart/mixed, but to reject parts
which are something other than text/plain (or arguably text/enriched).
The non-patched behavior of slrn is to fail to process properly standards
compliant text/plain parts. There are better ways to be text only.
> slrn focussed on the important features of a newsreader, like threading,
> scoring etc.
I don't want to get into slrn vs pine as a newsreader. If I didn't want
access to my IMAP folders when reading news, I wouldn't be using (al)pine
for news.
> Since when pine was able to to threading?
Someone can dig through revision history, but I think that it's been at
least eight years.
> On Tue, 25 Sep 2007, Thomas Wiegner wrote:
>
> :) But the thing is, usenet is a text only medium, there is no need for
> :) multipart/mixed, except for binary groups.
Please use a standard quote marker.
--
Ted S.
fedya at bestweb dot net
:) > You see, I've never converted anyone to Pine, because despite Pine
:) > being a wonderful program does not have a GUI. It's time to move to a
:) > new usenet, one that follows the trends of the time.
:)
:) So the trend being to Google Groups and other klunky web gateways for
:) the incompetent, you're sending them there where they may not even know
:) they're *using* Usenet? No, I'm not suggesting that that's a good
:) idea; please see my sig for an indication of my stance on that.
I am only suggesting that technology is there for a purpose. To improve
your life. Some people think that those gateways are good. One does not
need to know the final technology that supports it, like most people do
not know that webmail is an interfacte to IMAP. In fact, I've seen many
people that think that webmail is better than pop3, but would not try
IMAP. lol.
Interfaces are not the issue. The point is where the technology that
sustains that interface is going. I've always defended text messages, over
any other content, but I am not blind to see that sometimes plain test
just doesn't cut it, Now if you don't believe in technology, I have a 1897
cart that I am selling. It does not have gps, but is 2WD. Interested?
--
Eduardo
http://staff.washington.edu/chappa/pine/