Page History
- 2006-Dec-13 22:03 anonymous
- 2005-Aug-03 17:07 anonymous
- 2004-Dec-29 17:50 anonymous
- 2004-Dec-29 17:49 anonymous
- 2004-Jun-17 18:59 anonymous
- 2004-May-28 10:44 anonymous
- 2004-May-28 10:43 anonymous
- 2004-May-03 16:28 anonymous
- 2004-May-03 15:54 anonymous
- 2004-May-01 04:14 anonymous
- 2004-Apr-30 21:08 dougcurrie
- 2004-Apr-30 21:07 dougcurrie
- 2004-Apr-30 15:37 anonymous
- 2004-Apr-30 12:26 anonymous
- 2004-Apr-30 12:21 anonymous
- 2004-Apr-30 05:28 anonymous
- 2004-Apr-30 01:50 anonymous
- 2004-Apr-29 15:06 anonymous
My idea was a network protocol for sqlite database. This would be a client and a server libraries communicating over network(probably sockets). The client library wold have the same interface as current version of sqlite.so (sqlite.dll). The server library would be a wrapper around exsisting sqlite library.
Problems:
- Since the callback and VM API's would be to slow over network, it is neccessary to reimplement them on the client side to provide compatibility to the standard sqlite library.
- Passing pointers over network is not a good idea. (e.g. pointer to database, or to VM). They should be replaced by handles.
- Encoding of strings and integers. Distinguish between empty string and NULL string. BIG_ENDIAN/LITTLE_ENDIAN and so on.
- Security
- Performance
Implementation architecture: RPC or Sockets?
I tried out the rpcgen (generator of RPC). It generates a lot of useful code, but it can't handle NULL strings returned by sqlite.
Perhaps using sockets is a better idea.
Any suggestions and ideas are welcome.
Alex K.