World: r3wp

to keep the cli open, using telnet into localhost ?

well if this is working the connector will be great. this weekend 
I can post the source so far...

the test I made was against a real big table with 50+ mio records. 
no problem at all.

I wonder how it works inserting large text ( blobs )

I don't see any problem. cli's are also used for very large dumps 
or restores.

as said I am impressed by the robustness of this approach.

Ok, I'm waiting for the report on Saturday

sure captain ;-)

I'm getting my red pencil ready :)

:-))

will post the link saturday into the db group.

is CLI connector done in REBOL? Or does it call some external command-line 
cross-db access tool and REBOL just parses the data?

Theoretically it could be done all in REBOL. E.g. SQLite has sqlite.exe, 
MS SQL has some executable for querying the db too. I just thought, 
that calling command line tool is going to be orders of magnitude 
slower, than ODBC access ... at least under Windows ...

pekr, can't confirm this (under linux where I am using this connector). 

a standard hot wildcard query (select * from db limit 1000) takes 
in average 320 ms 

with cli and 560 ms with docs cool mysql driver which I am using 
daily. 

I think it looks different if you compare e.g cli against sqlite, 
connected via native 

lib access but all connectors working via tcp shouldn't be faster 
then cli I guess. 
but please don't nail me with these numbers.

this cli connector is currently a prototype idea with some nice potential 
at this

moment nothing more, at least it works very smooth for migration 
tasks.

the best is if you make your own tests and see if its usefull for 
your demands.

one addition: increasing/decreasing the resultset makes the difference 
much bigger 

in both directions. selecting 5000 records: cli/620 ms and scheme/3340 
ms
but selecting 10 records: cli/316 ms and scheme/35 ms.

so looks like the payload for starting the cli process is around 
300 ms.

as mentioned before, a concept holding the cli stable alive could 
save this payload.

2'000 concurrent calls .. 50% of 1 cpu or of all 4 cores ?

If this works out, it might be cool to write it as a port scheme 
so that we can just replace the 'open

Many of these isql/cli tools are open source ... I wonder how easy 
it would be to modify them to allow greater interactivity

the cli is currently using the original utilities from the db manufacturer 
to ensure max. performance and robustness. 

there are already many switches to modify out & input. for example 
take a look here for the monetdb switches:

http://monetdb.cwi.nl/XQuery/Documentation/The-Mapi-Client-Utility.html#The-Mapi-Client-Utility

there are 3 extension which would be very cool. 

1. tcp server for easy remote request  without the need for the cli 
on the client side (e.g. rebservice)  

2. a smart sql-syntax mapper for interactive migration (you can't 
read e.g. a mysql dump directly into postgresql) 

3. a stable cli alive holder to eliminate the startup payload for 
the request.

Something along the lines of the xml-odbc server that Easysoft sells 
.. but native and not odbc.

This waits for incoming xml requests and sends data back

yes, exactly but without the word odbc :)

btw, the cpu load was ~50% over all cores for approx. 5 sec. on an 
ubuntu dektop 8.10 running also 2  vbox vm's.

Interbase have a developer release that is multicore aware.  I'd 
be interested to test this once you do the first release.  The developer 
release is same as the commercial one but stops receiving new connections 
after 48 hours.

Firebird can only use one core.

interesting, will try this one. yes you are right multicore support 
makes sense.

if you like firebird you should also take a look to frontbase. running 
well with windows if you prefer, similar small footprint concept, 
but all in. replication, clustering, embedding etc.
there is also a streamline cli (sql92).

easy to integrate frontbase to the cli connector. one strength of 
this concept.

I use Firebird because I am used to it!

maybe we should shift this to DB

Your work sounds very cool Tomas. I'm sure Graham will give it a 
good test and report back. You may have a lot of people interested.

BTW, I made a couple of tiny changes to prot smtp, pop, and send 
to allow them to work with SSL.  Should these also make it into 2.7.8 
??

Sounds good to me. Which services/variants do your changes work with?

the ones I mentioned ?

Yup.

Yes.

No, I mean the server-side services, official protocol specs, etc.

I don't understand the question then.

You did the client-side stuff, but iirc those particular protocols 
aren't implemented very consistently between services, particularly 
with SSL. Which services have you tested your clients with? Gmail?

Gmail and hotmail

OK, cool :)

that covers 99.9% of the world's email services

http://rebol.wik.is/Protocols

and pop3 http://compkarori.no-ip.biz:8090/@api/deki/files/560/=prot-spop.r

I've got a demo script somewhere that logs in to hotmail/gmail and 
downloads all new messages and strips out the attachments

Found it http://accessories.s3.amazonaws.com/hotmailer.r

Is it Gmail-style POP3 over TLS on port 995, or is it RFC2595 STLS 
negotiation?

It might be a good idea to have the standard pop:// protocol do the 
STLS negotiation, and have pops:// do POP3S like Gmail.

That way we can support both.