World: r3wp

whoa, it does datatype translations :-) " [[1 "Petr" "Krenzelok" 
"This is pekr" 33] [2 "Marek" "Krenzelok" "This is pekrs brother" 
31]]"

Doc, are you sure the low-level protocl changed? The protocol is 
still version 10, which you have covered already. What is more, it 
is strange, as you can work with old passwords, without the change 
to the stack, so I would let it as it is, just let's correctly implement 
the password stuff as first step :-)

I mean - let's find out the way of how to distinguish there is new 
password scheme used for connection. I thought that LONG_FLAG or 
PROTOCOL_411 flags will be set, but they apparently are not set. 
Maybe we could distinguish by long-seed length? If it is still 8, 
then old password scheme should be used, if it is 20, then new password 
scheme is used?

aha - LONG_FLAG = long column info ...

it seems to me your older code was inspired by - http://svn.mysql.com/svnpublic/connector-net/trunk/mysqlclient/nativedriver.cs
?

Doc, are you sure your 'docode table is ok? I mean defs/client ....

client [
			long-password		1		; new more secure passwords
			found-rows			2		; Found instead of affected rows
			long-flag			4		; Get all column flags
			connect-with-db		8		; One can specify db on connect
			no-schema			16		; Don't allow db.table.column
			compress			32		; Can use compression protcol
			odbc				64		; Odbc client
			local-files			128		; Can use LOAD DATA LOCAL
			ignore-space		256		; Ignore spaces before '('
			change-user			512		; Support the mysql_change_user()
			interactive			1024	; This is an interactive client
			ssl					2048	; Switch to SSL after handshake
			ignore-sigpipe		4096	; IGNORE sigpipes
			transactions		8196	; Client knows about transactions
		]

While in protocol description, there is:

MySQL uses the following codes:
Capability name	Value	Meaning
LONG_PASSWORD	1	New more secure passwords
FOUND_ROWS	2	Found instead of affected rows
LONG_FLAG	4	Get all column flags
CONNECT_WITH_DB	8	One can specify db on connect
NO_SCHEMA	16	Don't allow database.table.column
COMPRESS	32	Can use compression protocol
ODBC	64	ODBC client
LOCAL_FILES	128	Can use LOAD DATA LOCAL
IGNORE_SPACE	256	Ignore spaces before '('
PROTOCOL_41	512	Support the 4.1 protocol
INTERACTIVE	1024	This is an interactive client
SSL	2048	Switch to SSL after handshake
IGNORE_SIGPIPE	4096	IGNORE sigpipes
TRANSACTIONS	8192	Client knows about transactions
SECURE_CONNECTION	32768	New 4.1 authentication
MULTI_STATEMENTS	65536	Multi-statement support
MULTI_RESULTS	131072	Multi-results

ah, extended the table and it shows:

----- Server ------
Version: 5.0.18-nt
Protocol version: 10
Thread ID: 36
Crypt Seed: iR=xh!fb
Capabilities: [
    long-flag
    connect-with-db
    compress
    protocol-41
    transactions
    secure-connection
]

newer version uploaded - now you can see there is protocol-41 flag, 
as well as secure-connection, according to which you can decide new 
auth. method was used imo ...

enough for today :-)

so, if you don't confirm there were changes in low-level protocol 
handling (reading, sending, flushing etc. code), then I can adapt 
the code to automatically distinguish for old/new auth scheme and 
respond accordingly. That could be some intermediate version for 
ppl to use ...

My old MySQL code is inpired by mm_mysql driver (now obsolete). The 
driver source code in C# you're pointing too is inspired by later 
evolutions of the mm_mysql driver.

so what is your opinion on the stack?

I think, that with "my" latest version, I now only need to distinguish 
authentication mode ... and to call scramble-long accordingly ....

MySQL server protocol has changed since 4.1.0 (with a big evolution 
starting from 4.1.1) and is not compatible with the older protocol. 
Strangely, server v5 allow clients to connect with the older (pre-4.1) 
protocol providing the good flags...(that's odd). Need more investigation 
to see if the old driver can still be used reliably with v5.

maybe better as a refinement of scramble itself ...

that is what I wanted to ask - did it really change?

I thought there is v9 and v10 protocols, and that only change was 
for auth. scheme ...

From 4.1.1, there's a lot of changes in the protocol, mainly a lot 
of new fields.

The protocol number hasn't been incremented, the server and client 
code in libmysql is messy...

so this is not accurate? http://www.redferni.uklinux.net/mysql/MySQL-Protocol.html

it seems to me as proper description of all communication phases 
...

well - so why it works so far for me?

yes it is, AFAICT. But it's protocol 4.1.1+, not the old one that 
is implemented in my driver.

aha, so actually what I did is that I extended parser for greetings 
phase, and also updated some locals table, watching carefully where 
such items are used - so far so good ...

I would be able to write it according to specs imo according to above 
protocol, but - I don't understand rebol port model, so :-(

and also - I would fire all old scrambler :-) but then old pre 4.11 
users would be at ends :-)

The server has still the support code for all protocol versions. 
That's why the old code is working, but according to the flags, (especially 
protocol_41), it should have rejected your connection. That's why 
I found it odd that your code was working. Anyway, let try to use 
this to make it work with the older code.

or do you think that checksum/secure could be used even for older 
mysql versions? I wonder if their scheme used sha1 in old days?

no, it wasn't 'sha1, it was a "poor man" hashing method.

I think I know why ... maybe :-) ..... simply put, I don't send protocol_41 
back after the greetings phase ...

Yes, I guess that's the trigger.

hmm, I will try to change that here :-)

latest version: http://www.rebol.cz/mysql/mysql-protocol-new.r

Ok, I'll make some changes to your code to make it work properly 
with 3.x and 4.1.x+ versions, then I'll launch my unit tests and 
see if it  is ok.

Your code doesn't deal with empty passwords, I'll fix that.

I know ... thanks ....!!!

New My

New MySQL driver version 1.0.0 supporting server v4.1.1+ : http://softinnov.org/tmp/mysql-protocol.r

This is a beta release, please report here any bugs.

This driver has not been tested with server version 3.x.

Softinnov.org was down for a couple of hours for server PSU replacement. 
The download link works now again.

Dock, if you publish a new version of mysql-protocol.r, it's time 
to make the correction of the bug in the init function, the longlong 
conversion and in the data reading initialization.

what bugs?

have you any fixes?

what is wrong with init, longlong conversion and in data reading 
initialisation in particular?

The init function fails with this for eaxample :

   open join mysql://user:[password-:-my-:-super-:-server]/my-db? "select * 
   from my-table"
or something like that I don't remember

I would expect that - why is your db query part of opening sequence?

with read, it would make sense ...

Yes perhaps, it fails also with read

I am of course for fixing all possible bugs, but just now simply 
everything seems to work, we are able to connect to new dbs, that 
was main point ...