On 20 Dec 2010, at 22:18, Simon Slavin wrote: > > On 20 Dec 2010, at 9:02pm, Richard Hipp wrote: > >> (2) Create your own custom mini-SQL-server using SQLite and your own >> protocol for your applications to talk to that min-server over the network. > > In your opinion (or in the opinion of anyone else intimately familiar with > SQLite), is SQLite suited to this ? It could be done as a standard package, > provided and supported by the same team that supports standard SQLite and > provided in the same amalgamated form. The procedure would presumably be > something like: > > 1) Pick a pair of ports for the protocol and start the process of getting the > IETF to recognise them. > 2) Devise a protocol to encode all the functions in > <http://www.sqlite.org/c3ref/funclist.html> so they can be used over IP. > 3) Do the programming for the server and client. > > Does the team think it's worth doing this ? Or will the vast majority of > people who need networked SQL also need a bunch of other features like user > privilages which mean you might as well just use one of the existing 'big' > SQLs ?
I'm not "intimately familiar with SQLite" but I do have a lot of experience in this kind of work: I was employed by IBM as part of the WebSphere MQ (aka MQSeries) development team for 7 years before I set up my own company. The bulk of the code and almost all of the complexity in such systems is to deal with the problem that the data is managed by/in one address-space and needs to be used by/in another address-space. User authentication/authorisation and I suspect the rest of the 'bunch of other features' are not a big deal compared to the pervasive structural differences enforced by dealing with this problem (as compared to deliberately not dealing with it). SQLite is deliberately designed not to try and solve it. I imagine you would meet a lot of resistance if you tried to insert that complexity into SQLite when it has been so deliberately avoided: I certainly wouldn't want it slowing down my apps. Inserting a network between the two address-spaces doesn't change much code in the short term, but it does change the balance of where you put processing: try to send the minimum data in the minimum number of conversations across the network. Notes on your procedure: 1) You only need to specify the server port; not sure why you think you need another. It is hard but not terribly hard to get a recognised port; it helps if you ask IANA and not the IETF, as they own the list. You should also question whether you require a fixed port as doing so precludes running more than one instance per IP address. I would argue that it is better today to use unpredictable port numbers and dns-sd to identify where the instance you want is available. 2) Protocol design is difficult to do at all and extremely difficult to do well. For example, how would you implement sqlite3_create_function-installed user functions in such a way that transactions are never blocked for ludicrous amounts of time waiting for results. There are other more difficult problems but this one is the easiest difficult one to understand. 3) This is the easy bit. My hunch is that if this were done the result would be something no-one wants: not much smaller than Postgres/MySQL/etc, as complex to use as Postgres/MySQL/etc (more so as most stuff you want to achieve with those can be done with google and copy/paste), and probably significantly slower. Best Regards, Phil Willoughby -- Managing Director, StrawberryCat Limited StrawberryCat Limited is registered in England and Wales with Company No. 7234809. The registered office address of StrawberryCat Limited is: 107 Morgan Le Fay Drive Eastleigh SO53 4JH _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
