Hi! I've been working on the new client library for drizzle, and while doing so, have been brainstorming ways to improve the client-server protocol. I'm going to start putting together a new protocol specification and am curious what improvements and features people would like to see. I've discussed this somewhat with Brian and a few others already. Here are some ideas that came up, along with other thoughts I had:
* Dynamic, extensible protocol while still focusing on speed and parsing efficiency. The MySQL protocol has not aged well with the additions made to it over the years. * Concurrent query support for a single socket connection. This means tagging each query with an identifier so multiple query and result packets can be interleaved on the wire. * No authentication by default. You connect, establish capabilities with no authentication, and then issue a query. If the server requires credentials for a query, it will ask for them (much like HTTP). * Support for arbitrary authentication methods. With plug-in support for auth in the server, it is natural to extend this to allow authentication protocols to be modular. A simple hash may suffice for some (like MySQL does now), but others may require a 3-way authentication (as Mark suggested). This means plug-ins within a drizzle protocol library, and capabilities can be announced during negotiation much like SSL/TLS negotiates ciphers. * Check-sums. This has been suggested, but do we need to do this even though the IP and TCP layers already do? This may come down to a question of whether we will want to push the protocol over other layers that do not already have check-sums. * UDP support. For client-server communication in a dedicated, reliable packet environment, this could be useful to avoid TCP throttling and congestion control. * SSL/TLS support. I would like to see support for this continued. * Not returning non-string fields in string format. Does it make sense to return an integer field as a string? What about returning fields in their native binary format (network-endian) which then translate to the native client representation? How would a new client interface look for this? * Large blob handling. Does this need to reworked to allow streaming before knowing the full size? Think of a chunked Transfer-Encoding in a HTTP response. * Compression. Thoughts on this? Perhaps a modular interface like authentication methods? * HTTP support. This means supporting SQL queries layered on top of the HTTP protocol. This may be useful for some web clients, and may be something to look at further down the road. Any other thoughts of issues people have in mind? What do people see as important items to implement? -Eric _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : drizzle-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
