World: r3wp
[!REBOL2 Releases] Discuss 2.x releases
older newer | first last |
Pekr 15-Apr-2010 [1467x2] | 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 ... | |
TomBon 15-Apr-2010 [1469x2] | 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. | |
Graham 15-Apr-2010 [1471x3] | 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 | |
TomBon 15-Apr-2010 [1474x2] | 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. | |
Graham 15-Apr-2010 [1476x2] | 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 | |
TomBon 15-Apr-2010 [1478x2] | 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. | |
Graham 15-Apr-2010 [1480x2] | 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. | |
TomBon 15-Apr-2010 [1482x3] | 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. | |
Graham 15-Apr-2010 [1485x2] | I use Firebird because I am used to it! |
maybe we should shift this to DB | |
Gregg 15-Apr-2010 [1487] | 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. |
Graham 16-Apr-2010 [1488] | 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 ?? |
BrianH 17-Apr-2010 [1489] | Sounds good to me. Which services/variants do your changes work with? |
Graham 17-Apr-2010 [1490] | the ones I mentioned ? |
BrianH 17-Apr-2010 [1491] | Yup. |
Graham 17-Apr-2010 [1492] | Yes. |
BrianH 17-Apr-2010 [1493] | No, I mean the server-side services, official protocol specs, etc. |
Graham 17-Apr-2010 [1494] | I don't understand the question then. |
BrianH 17-Apr-2010 [1495] | 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? |
Graham 17-Apr-2010 [1496] | Gmail and hotmail |
BrianH 17-Apr-2010 [1497] | OK, cool :) |
Graham 17-Apr-2010 [1498x5] | 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 | |
BrianH 17-Apr-2010 [1503x4] | 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. | |
Same with imap:// vs. imaps://. | |
Graham 17-Apr-2010 [1507] | I keep thinking that rebol doesn't do tls ... but if it does, I don't use it |
BrianH 17-Apr-2010 [1508] | I meant your fixes, not what REBOL does now :) |
Graham 17-Apr-2010 [1509] | Well my fixes are just to open the secure port ... that's it |
BrianH 17-Apr-2010 [1510] | Ah, pops then. spop would be pop over ssh :) |
Graham 17-Apr-2010 [1511x3] | pops it is then |
what's secure smtp ? | |
smtps ? | |
BrianH 17-Apr-2010 [1514] | Yes. |
Graham 17-Apr-2010 [1515x2] | Ok, I didn't know the naming schemes |
so ssend => sends :) | |
older newer | first last |