we have concurrency!
Matthew Scott
the conclusion that Schevo should stay as-is, but should be outfitted
to support concurrency via the use of a client/server protocol.
I'm happy to report that much progress has been made!
I've been able to do the following:
- Create, open, and evolve arbitrary Schevo databases over the wire
- Connect to the same database more than once
- Connect to Schevo databases over the wire with "schevo shell"
- Use the PyGTK navigator with a database over the wire
There's still much to do, but I am lining up at least one or two
projects that will be making use of Schevo for public-facing
websites. They were going to be based on something else, but I'm
happy enough with the progress I've made in the last two days that I
am going to go for it and finally get Schevo into the web trenches.
The final solution was this:
- Durus extended server (Duruses) project
- extension of the existing Durus client/server protocol
- supports multiple databases with one server
- server rewritten to use cogen
- clean asynchronous code
- platform-specific performance optimizations
- uses epoll/kqueue on Linux/BSD
- uses iocp on Windows
- Outfit Schevo to support Duruses
- Now uses URLs to refer to local files or remote databases
- Awareness of read/write conflicts, with automatic transaction retry
Three alternatives were considered but thrown out for these reasons:
- rewrite of Schevo to use a SQL backend
- VERY complex undertaking
- wouldn't benefit from it much, and would probably have had to take
away good features
- server-less concurrency using Durus and file tricks
- complex undertaking
- potential severe performance problems
- existing Durus client/server
- only one file served at a time
- impedes the all-important "playfulness" of effective development
- potential headaches with deployment as well