World: r3wp

i mean, if noone in the world will ever need the fallback, there's 
no point in adding it. in weird cases when you have to work with 
some 15 years old server, you may just use the old smtp:// protocol.

as long as you make the error obvious, I guess its better to be strict 
about it.

fall back.

if you write a simple smtp server in rebol you might just want to 
support helo only

graham - did you stumble on any servers not liking EHLO? if you did, 
then I guess we need to fallback

no, actually, you can support EHLO and have no extensions.

not supporting ehlo in a server makes your server not rfc compliant

let me check if my own smtp server supports ehlo :)

http://www.compkarori.com/vanilla/display/Smtpd.r

suports EHLO .. so I guess you're okay!

i think you're the person that better knows how smtp servers behave 
out there. :)

there are some pretty ancient smtp servers out there ...

if an ordinary user would stumble into the problem, then it's probably 
better to fallback.

that way we only need one protocol ..

Gabriele, why don't we run without the fallback for a while to see 
if it will affect anyone. I don't see the reason to add code "just 
in case" when there might in fact be no case like that.

You could keep the fallback code in there ready to be uncommented 
when someone complains.

anton, it might only be a couple of lines to fall back.

and I would think most email clients would fall back ...

it's not a big deal indeed, it just means disabling the rest of the 
code - that's why it seems quite weird to me :)

It's not worth the hassle of not putting it in.

How about net-logging a prominent message when falling back ? That 
way, it should eventually turn up in someone's log, and we'll see 
it that way.

good idea... that way any techie does not miss it, if its at all 
important.  and any average user, gets improved mileage without the 
hassle.

Anton, it will be in the build ... do you really want to update all 
builds once someone reports a problem

ok, i guess i will add the fall back.

I'm just always trying to find "the correct thing to do".

I am accepting #4143. note, that although i think it is unlikely, 
this change could break old code that made assumptions about switch. 
so please do test this one when released (i assume 2.7.2), and if 
it breaks code, we can revert to the old switch, and maybe add a 
refinement or something like that.

anyone has the original contents of #3056?

can anyone check if #3666 still applies?

gabriele, is 3056 not listed in http://www.rebol.net/cgi-bin/projects/share.r?id=35&
?

http://www.rebol.net/cgi-bin/projects/share.r<--- interesting, I 
don't remember this page?

the urls for various code submissions contain spaces, so that breaks 
all the links

ah, that script is still working? :)

#3666 "CALL interferes with UDP ports"  - doesn't seem to apply on 
Windows Rebol/View, I've tested about 30 versions so far.

Just to be sure... when running the second server, I should expect 
a print out of "false-awake-event" to indicate the bug, shouldn't 
I ?

I didn't see this printout on any Rebol/View 1.2.1.3.1 -> 2.7.0.3.1

#3666 applies to Linux: 1.3.2.4.2 and OpenBSD

re #4143: as I mentioned elsewhere, I would prefer FIND/LITERAL or 
changed FIND/ONLY to get more expected result for datatypes

(and I guess, that #3666 may apply to OSX too)

(Ladislav, well, I'm sure of that now !  I should have paid attention 
to the version numbers.)

#4143: yes, but what i think could break code, is people expecting 
this to work:

>> switch 2 [2 1]
== 1

it won't with the new switch. it's unlikely anyone is doing that... 
but it's possible :)

looks like Holger used that feature:

switch port/locals/access/type [
            list [
                port/locals/list: copy* []
                port/state/tail: 0

                imap-check port reform [uppercase port/locals/access/list {""}

                    imap-form-string port/locals/access/name] none [ok]
            ]
            box select-block
            iuid [
                do select-block
                port/state/tail: 1
            ]
            search [
                port/locals/msg-uids: copy* []
                do select-block

                imap-check port reform ["UID SEARCH" port/locals/access/search] none 
                [ok]
                port/state/tail: length? port/locals/msg-uids
            ]
        ]

(imap protocol)

notice    box select-block

anyone else doing this?

I made an observation while using FTP a couple of months ago that 
login names couldn't contain the \ character. I've found that certain 
web providers use \ by standard in their user names to separate the 
user's name with server name. This is non standard, but not likely 
that the webhost will change this policy.

This can be changed with:


net-utils/url-parser/user-char: union net-utils/url-parser/user-char 
make bitset! #"\"


If I hadn't known this, I would not have been able to use this webhost 
(one of my customers have all his sites there). It gave me a lot 
of head scratching, but Pekr found this solution for me. I imagine 
that other REBOL users will face the same problem.

Should it be included even though it's non-standard?

RAMBO'ed

An ever-present question. I guess being non-standard, the character 
can cause trouble in another situation. Then who is to blame ?