git://git.hackndev.com/farcaller/fow.git

Mercurial repo is kept in sync.

Cocotron’s Obj-C runtime doesn’t support properties introspection, so for each descendant of SQLitePersistentObject you must define following selector:

+ (NSArray *)getPropertiesList;

It must return an array of all properties in form of NSArrays with two items: property name and encoded type:

+ (NSArray *)getPropertiesList
{
        return [NSArray arrayWithObjects:
                [NSArray arrayWithObjects:@"name", @"@\"NSString\"", nil],
                [NSArray arrayWithObjects:@"favoriteInt", @"i", nil],
                [NSArray arrayWithObjects:@"birthDate", @"@\"NSDate\"", nil],
        nil];
}

You can get full list of types either from SQLitePersistentObject.h or Cocoa documentation.

Benchmark consisted of resolving a typical URL regexp, loading handler, loading template and rendering static context onto it. Both Django and FOW were running with 2 threads attached to lighttpd via FCGI.

Django:

Concurrency Level:      20
Time taken for tests:   0.403 seconds
Complete requests:      500
Failed requests:        421
   (Connect: 0, Receive: 0, Length: 421, Exceptions: 0)
Write errors:           0
Non-2xx responses:      421
Keep-Alive requests:    403
Total transferred:      257544 bytes
HTML transferred:       173835 bytes
Requests per second:    1239.72 [#/sec] (mean)
Time per request:       16.133 [ms] (mean)
Time per request:       0.807 [ms] (mean, across all concurrent requests)
Transfer rate:          623.60 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       3
Processing:     1   12  23.1      3     188
Waiting:        1   12  22.7      3     162
Total:          1   12  23.3      3     188

Percentage of the requests served within a certain time (ms)
  50%      3
  66%      3
  75%      3
  80%      4
  90%     64
  95%     66
  98%     68
  99%     76
 100%    188 (longest request)

FOW:

Concurrency Level:      20
Time taken for tests:   0.916 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Keep-Alive requests:    480
Total transferred:      179400 bytes
HTML transferred:       104000 bytes
Requests per second:    545.79 [#/sec] (mean)
Time per request:       36.644 [ms] (mean)
Time per request:       1.832 [ms] (mean, across all concurrent requests)
Transfer rate:          191.24 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:     7   36  14.8     29      83
Waiting:        7   36  14.8     29      83
Total:          7   36  14.8     29      83

Percentage of the requests served within a certain time (ms)
  50%     29
  66%     32
  75%     41
  80%     45
  90%     53
  95%     81
  98%     82
  99%     82
 100%     83 (longest request)

Today I’ve thought that FOW is mature enough to be tested on my linux hardware, so I’ve got updated Cocotron and built FOW on linux.

I have to say lots of thanks to Johannes Fortmann, who has been answering all my stupid questions about GCC, Obj-C runtime and Cocotron.

Now, it is time to really publish some sources

What’s FOWCore? That’s an FOW-based application, that you can use if you don’t want to go low-level with FOW. You write handlers in bundles, and then FOWCore will dynamically load and register handling stuff.

Currently that works via config file. First you list all the bundles you use:

	<key>bundles</key>
	<array>
		<string>../test_servers/TestBundle/build/Debug/TestBundle.bundle</string>
		...
	</array>

then you configure URL mappings, by providing URL regexp, class name, bundle for class and selector:

	<key>handlers</key>
	<array>
		<dict>
			<key>url</key>
			<string>get/(.*)</string>
			<key>bundle</key>
			<string>org.hackndev.TestBundle</string>
			<key>class</key>
			<string>TestBundle</string>
			<key>selector</key>
			<string>handleGet:</string>
		</dict>
		<dict>
			<key>url</key>
			<string>post/(.*)</string>
			<key>bundle</key>
			<string>org.hackndev.TestBundle</string>
			<key>class</key>
			<string>TestBundle</string>
			<key>selector</key>
			<string>handlePost:</string>
		</dict>
	</array>

I’m considering two ways to configure a running FOWCore application: either by web interface (there would be thing like “webconf.bundle” in FOWCore) or by a configuration utility that would connect to FOWCore instance via unix socket.

Now working on sessions implementation. Still considering between memcached and sqlite3, but seems that latter is winning. Sessions are more about persistance than speed.

• Got HTTP server from Google Toolbox. It might be useful for testing the code;
• ActiveRecord looked too complex for me. You can use anything you want for your ORM, but seems that there will be only some DB abstraction layer in FOW for now (yup, plain old SQL);
• MGTemplateEngine is a very interesting django-looking thing. Might be bundled alongside with Google’s CTemplate engine;
• Source code tree is mostly stabilised now.

I have some plans to bundle FOW with a launcher code, that would allow one to have an already compiled fcgi application that would just load handler bundles (and unload, so you could update code in nearly runtime). Flexibility is good. Complexity is not.

It took some time to re-implement old functionality, unit tests are still broken, but now I consider some of the advertised functionality as useless. I’ll implement it later if I would really require things like reconstructing request URL or detecting https.

More new stuff. Now FOWRequest parses GET and simple POST requests on its own (still have to implement multipart stuff).

I’ve got some plans for session manager. Most possibly it would be based on configurable sqlite (one more dependency) storage. You can choose either in-memory or disk file based on your needs.

Still have to fix Cocotron build script, I really hope to make pre-pre-alpha release this week