Recent changes to Home

Home modified by Francesco Montorsi

Francesco Montorsi — Tue, 09 Apr 2013 18:19:12 -0000

--- v10
+++ v11
@@ -26,7 +26,6 @@
 - Poor latency when another user is running a very big query (although clients may be forced to limit their queries, which IMHO is a good thing in any database scenario).

-Read more
----------
+### Read more ###
 For more info about the protocol, you can read the [TechFell protocol] page. 
 For more info about uSQLite code, you can read the [FAQ] page.

Home modified by Francesco Montorsi

Francesco Montorsi — Tue, 09 Apr 2013 18:18:49 -0000

--- v9
+++ v10
@@ -1,9 +1,6 @@
-uSQLite - An SQLite network wrapper
-===================================
+# uSQLite - An SQLite network wrapper #

-
-What is it?
------------
+### What is it? ###
 uSQLite is a network wrapper for [SQLite](http://www.sqlite.org/). It turns SQLite into an RDBMS but puts the emphasis on the 'Lite'. In fact it works in a somewhat unconventional mmanner in order to make both servers and clients as light, portable and simple as possible. Readers who are not familiar with SQLite are advised to visit http://www.sqlite.org.

 uSQLite uses the [TechFell protocol] for communications between clients and servers. This protocol was originally designed for allowing embedded systems to directly access a database, but has proved efficient in more general applications and in conjunction with a suitable server (such as uSQLite server) may also be used for inter-process and inter systems communications.
@@ -13,8 +10,7 @@
 In a more general scenario it has the advantage that custom client software may be built into the applications (it is very easy to write and customize drivers) such that applications may be deployed without the need for a separate database / database driver layer to install and/or configure, in essence a distributed embedded database.

-Features
---------
+### Features ###
 - Server supports concurrent users on a single mono threaded database connection, all queries are executed in strict sequential order.
 - Server can be compiled onto anything that has libc and Berkleyish sockets (including winsock2); for this reason all Windows and Linux/Unix systems are supported. No threading or filesystem locking is required.
 - Server startup parameters put limits on server resource usage. Client queries can be clamped.
@@ -25,8 +21,7 @@
 - No dependency on external mechanisms.

-Drawbacks
----------
+### Drawbacks ###
 - You may not use transactions (or more correctly, transactions must BEGIN and END in the same query or group of queries sent as a single batch)
 - Poor latency when another user is running a very big query (although clients may be forced to limit their queries, which IMHO is a good thing in any database scenario).

Home modified by Francesco Montorsi

Francesco Montorsi — Tue, 09 Apr 2013 09:05:20 -0000

--- v8
+++ v9
@@ -29,3 +29,9 @@
 ---------
 - You may not use transactions (or more correctly, transactions must BEGIN and END in the same query or group of queries sent as a single batch)
 - Poor latency when another user is running a very big query (although clients may be forced to limit their queries, which IMHO is a good thing in any database scenario).
+
+
+Read more
+---------
+For more info about the protocol, you can read the [TechFell protocol] page. 
+For more info about uSQLite code, you can read the [FAQ] page.

Home modified by Francesco Montorsi

Francesco Montorsi — Tue, 09 Apr 2013 08:50:44 -0000

--- v7
+++ v8
@@ -6,7 +6,7 @@
 -----------
 uSQLite is a network wrapper for [SQLite](http://www.sqlite.org/). It turns SQLite into an RDBMS but puts the emphasis on the 'Lite'. In fact it works in a somewhat unconventional mmanner in order to make both servers and clients as light, portable and simple as possible. Readers who are not familiar with SQLite are advised to visit http://www.sqlite.org.

-uSQLite uses the [[TechFell protocol]] for communications between clients and servers. This protocol was originally designed for allowing embedded systems to directly access a database, but has proved efficient in more general applications and in conjunction with a suitable server (such as uSQLite server) may also be used for inter-process and inter systems communications.
+uSQLite uses the [TechFell protocol] for communications between clients and servers. This protocol was originally designed for allowing embedded systems to directly access a database, but has proved efficient in more general applications and in conjunction with a suitable server (such as uSQLite server) may also be used for inter-process and inter systems communications.

 In automation systems it may be used to provide both database and communications in a single package, and in many cases can eliminate the need for communications middleware.

Home modified by Francesco Montorsi

Francesco Montorsi — Tue, 09 Apr 2013 08:49:32 -0000

--- v6
+++ v7
@@ -6,7 +6,7 @@
 -----------
 uSQLite is a network wrapper for [SQLite](http://www.sqlite.org/). It turns SQLite into an RDBMS but puts the emphasis on the 'Lite'. In fact it works in a somewhat unconventional mmanner in order to make both servers and clients as light, portable and simple as possible. Readers who are not familiar with SQLite are advised to visit http://www.sqlite.org.

-uSQLite uses the TechFell protocol for communications between clients and servers. This protocol was originally designed for allowing embedded systems to directly access a database, but has proved efficient in more general applications and in conjunction with a suitable server (such as uSQLite server) may also be used for inter-process and inter systems communications.
+uSQLite uses the [[TechFell protocol]] for communications between clients and servers. This protocol was originally designed for allowing embedded systems to directly access a database, but has proved efficient in more general applications and in conjunction with a suitable server (such as uSQLite server) may also be used for inter-process and inter systems communications.

 In automation systems it may be used to provide both database and communications in a single package, and in many cases can eliminate the need for communications middleware.

Home modified by Francesco Montorsi

Francesco Montorsi — Tue, 09 Apr 2013 08:40:21 -0000

--- v5
+++ v6
@@ -4,7 +4,7 @@

 What is it?
 -----------
-uSQLite is a network wrapper for [SQLite](http://www.sqlite.org/). It turns SQLite into an RDBMS but puts the emphasis on the 'Lite'. In fact it works in a somewhat unconventional mmanner in order to make both servers and clients as light, portable and simple as possible. Readers who are not familiar with SQLite are advised to visit .
+uSQLite is a network wrapper for [SQLite](http://www.sqlite.org/). It turns SQLite into an RDBMS but puts the emphasis on the 'Lite'. In fact it works in a somewhat unconventional mmanner in order to make both servers and clients as light, portable and simple as possible. Readers who are not familiar with SQLite are advised to visit http://www.sqlite.org.

 uSQLite uses the TechFell protocol for communications between clients and servers. This protocol was originally designed for allowing embedded systems to directly access a database, but has proved efficient in more general applications and in conjunction with a suitable server (such as uSQLite server) may also be used for inter-process and inter systems communications.

@@ -16,7 +16,7 @@
 Features
 --------
 - Server supports concurrent users on a single mono threaded database connection, all queries are executed in strict sequential order.
-- Server can be compiled onto anything that has libc and Berkleyish sockets (including winsock2). No threading or filesystem locking is required.
+- Server can be compiled onto anything that has libc and Berkleyish sockets (including winsock2); for this reason all Windows and Linux/Unix systems are supported. No threading or filesystem locking is required.
 - Server startup parameters put limits on server resource usage. Client queries can be clamped.
 - Uses a simple but effective built-in access control system that assigns access levels to both users and networks (or individual IP's).
 - Client access has a "Human" mode which allows telenetting into the server (primarily for commissioning and trouble shooting).

Home modified by Francesco Montorsi

Francesco Montorsi — Tue, 09 Apr 2013 08:38:41 -0000

--- v4
+++ v5
@@ -1,11 +1,10 @@
-uSQLiteServer - An SQLite network wrapper
-=========================================
+uSQLite - An SQLite network wrapper
+===================================

 What is it?
 -----------
-
-uSQLite is a network wrapper for SQLite. It turns SQLite into an RDBMS but puts the emphasis on the 'Lite'. In fact it works in a somewhat unconventional mmanner in order to make both servers and clients as light, portable and simple as possible. Readers who are not familiar with SQLite are advised to visit www.sqlite.org.
+uSQLite is a network wrapper for [SQLite](http://www.sqlite.org/). It turns SQLite into an RDBMS but puts the emphasis on the 'Lite'. In fact it works in a somewhat unconventional mmanner in order to make both servers and clients as light, portable and simple as possible. Readers who are not familiar with SQLite are advised to visit .

 uSQLite uses the TechFell protocol for communications between clients and servers. This protocol was originally designed for allowing embedded systems to directly access a database, but has proved efficient in more general applications and in conjunction with a suitable server (such as uSQLite server) may also be used for inter-process and inter systems communications.

@@ -16,7 +15,6 @@

 Features
 --------
-
 - Server supports concurrent users on a single mono threaded database connection, all queries are executed in strict sequential order.
 - Server can be compiled onto anything that has libc and Berkleyish sockets (including winsock2). No threading or filesystem locking is required.
 - Server startup parameters put limits on server resource usage. Client queries can be clamped.
@@ -29,6 +27,5 @@

 Drawbacks
 ---------
-
 - You may not use transactions (or more correctly, transactions must BEGIN and END in the same query or group of queries sent as a single batch)
 - Poor latency when another user is running a very big query (although clients may be forced to limit their queries, which IMHO is a good thing in any database scenario).

Home modified by Francesco Montorsi

Francesco Montorsi — Tue, 09 Apr 2013 08:36:56 -0000

--- v3
+++ v4
@@ -17,15 +17,18 @@
 Features
 --------

-Server supports concurrent users on a single mono threaded database connection, all queries are executed in strict sequential order.
-Server can be compiled onto anything that has libc and Berkleyish sockets (including winsock2). No threading or filesystem locking is required.
-Server startup parameters put limits on server resource usage. Client queries can be clamped.
-Uses a simple but effective built-in access control system that assigns access levels to both users and networks (or individual IP's).
-Client access has a "Human" mode which allows telenetting into the server (primarily for commissioning and trouble shooting).
-Clients are very simple, users can easily roll their own bindings into just about anything programmable with a TCP/IP stack.
-Users may share (actually must share) temporary tables and memory based tables (useful for IPC).
-No dependency on external mechanisms.
+- Server supports concurrent users on a single mono threaded database connection, all queries are executed in strict sequential order.
+- Server can be compiled onto anything that has libc and Berkleyish sockets (including winsock2). No threading or filesystem locking is required.
+- Server startup parameters put limits on server resource usage. Client queries can be clamped.
+- Uses a simple but effective built-in access control system that assigns access levels to both users and networks (or individual IP's).
+- Client access has a "Human" mode which allows telenetting into the server (primarily for commissioning and trouble shooting).
+- Clients are very simple, users can easily roll their own bindings into just about anything programmable with a TCP/IP stack.
+- Users may share (actually must share) temporary tables and memory based tables (useful for IPC).
+- No dependency on external mechanisms.
+
+
 Drawbacks
+---------

-You may not use transactions (or more correctly, transactions must BEGIN and END in the same query or group of queries sent as a single batch)
-Poor latency when another user is running a very big query (although clients may be forced to limit their queries, which IMHO is a good thing in any database scenario).
+- You may not use transactions (or more correctly, transactions must BEGIN and END in the same query or group of queries sent as a single batch)
+- Poor latency when another user is running a very big query (although clients may be forced to limit their queries, which IMHO is a good thing in any database scenario).

Home modified by Francesco Montorsi

Francesco Montorsi — Tue, 09 Apr 2013 08:35:15 -0000

--- v2
+++ v3
@@ -1,8 +1,9 @@
-uSQLiteServer
+uSQLiteServer - An SQLite network wrapper
+=========================================

-An SQLite network wrapper

 What is it?
+-----------

 uSQLite is a network wrapper for SQLite. It turns SQLite into an RDBMS but puts the emphasis on the 'Lite'. In fact it works in a somewhat unconventional mmanner in order to make both servers and clients as light, portable and simple as possible. Readers who are not familiar with SQLite are advised to visit www.sqlite.org.

@@ -12,7 +13,9 @@

 In a more general scenario it has the advantage that custom client software may be built into the applications (it is very easy to write and customize drivers) such that applications may be deployed without the need for a separate database / database driver layer to install and/or configure, in essence a distributed embedded database.

+
 Features
+--------

 Server supports concurrent users on a single mono threaded database connection, all queries are executed in strict sequential order.
 Server can be compiled onto anything that has libc and Berkleyish sockets (including winsock2). No threading or filesystem locking is required.

Home modified by Francesco Montorsi

Francesco Montorsi — Tue, 09 Apr 2013 08:32:08 -0000

--- v1
+++ v2
@@ -1,8 +1,28 @@
-Welcome to your wiki!
+uSQLiteServer

-This is the default page, edit it as you see fit. To add a new page simply reference it within brackets, e.g.: [SamplePage].
+An SQLite network wrapper

-The wiki uses [Markdown](/p/usqlite/wiki/markdown_syntax/) syntax.
+What is it?

-[[project_admins]]
-[[download_button]]
+uSQLite is a network wrapper for SQLite. It turns SQLite into an RDBMS but puts the emphasis on the 'Lite'. In fact it works in a somewhat unconventional mmanner in order to make both servers and clients as light, portable and simple as possible. Readers who are not familiar with SQLite are advised to visit www.sqlite.org.
+
+uSQLite uses the TechFell protocol for communications between clients and servers. This protocol was originally designed for allowing embedded systems to directly access a database, but has proved efficient in more general applications and in conjunction with a suitable server (such as uSQLite server) may also be used for inter-process and inter systems communications.
+
+In automation systems it may be used to provide both database and communications in a single package, and in many cases can eliminate the need for communications middleware.
+
+In a more general scenario it has the advantage that custom client software may be built into the applications (it is very easy to write and customize drivers) such that applications may be deployed without the need for a separate database / database driver layer to install and/or configure, in essence a distributed embedded database.
+
+Features
+
+Server supports concurrent users on a single mono threaded database connection, all queries are executed in strict sequential order.
+Server can be compiled onto anything that has libc and Berkleyish sockets (including winsock2). No threading or filesystem locking is required.
+Server startup parameters put limits on server resource usage. Client queries can be clamped.
+Uses a simple but effective built-in access control system that assigns access levels to both users and networks (or individual IP's).
+Client access has a "Human" mode which allows telenetting into the server (primarily for commissioning and trouble shooting).
+Clients are very simple, users can easily roll their own bindings into just about anything programmable with a TCP/IP stack.
+Users may share (actually must share) temporary tables and memory based tables (useful for IPC).
+No dependency on external mechanisms.
+Drawbacks
+
+You may not use transactions (or more correctly, transactions must BEGIN and END in the same query or group of queries sent as a single batch)
+Poor latency when another user is running a very big query (although clients may be forced to limit their queries, which IMHO is a good thing in any database scenario).