A general purpose trading system enabling financial exchanges contingent upon public events, e.g. the collective purchase of a music recording contingent upon the event of its public release.

It is to form the engine behind the Digital Art Auction and QuidMusic sites.

The Contingency Market is exposed as a web service, currently in development here: www.contingencymarket.com

A demonstration site, 1p2U, that uses the contingency market is also currently in development.

I had previously assumed that Contingency Market clients would digest and archive RSS feeds themselves given an underlying assumption that the CM would be RSS agnostic. Thus the CM client (such as 1p2U) would take it upon themselves to register all the appropriate RSS events.

However, being pragmatic about it, the CM is ideally placed to take upon the burden of monitoring RSS feeds itself, leaving clients with only a need to register the feed as an event (an automatically observed one). That way the client can then interrogate the CM for information concerning the history of that feed, e.g. all items published.

I’ve now completed the modifications to the CM.

What I’ve now got to do is remove 1p2U’s rather iffy code that digests the RSS feed and replace it with code that retrieves equivalent information concerning the RSS feed from the CM instead.

Once I’ve done that, there should no longer be gaps in articles, nor cases where subscribers are listed more than once for the same feed.

A couple of days perhaps? :-}

I have been intending for the Contingency Market API to operate efficiently remotely as well as locally, hence its current, rather sluggish setup my end to replicate such a use.

However, in wishing to progress a little more quickly with 1p2U, I think I’ll leave the implementation of an object cache for the CM API until a little later (given I doubt there are any API users apart from myself at the mo).

Incidentally, the CM back-end database has been designed from the outset to be bidirectionally replicatable. So that provides an alternative to achieving a similar result via the API keyhole.

As far as my immediate next steps are concerned I’m going to try out an alternative API cache, then ameliorate my deliberate server-side bottleneck, and finally migrate data processing from the page retrieval process to a background one. Page caching is another option, but I’m leaving that until last.

So, 1p2U will not change visually/functionally for a few days, despite a long list of things needing to be done.

I’ve fixed the Contingency Market cache to cope with larger API call results.

I’m now going to do a tadette of profiling on 1p2U to see whether time is taken in database access or SOAP communication.

It would also no doubt help if 1p2U was a little less greedy in the amount of data it requested, but at least it gives me an opportunity to profile where the time is taken when dealing with large amounts of data.

The CM PHP API cache crashed yesterday evening, so I have disabled it until I’ve fixed the bug (the call result to be cached was too large).

Apologies for accidentally sending out an e-mail yesterday to each 1p2U/Contingency Market user to re-authenticate their e-mail address. This was caused by my direct edit of the user database. I have since amended the code (shut the barn door) such that this won’t happen again (for the same reason anyway).

The 0.9 version of the PHP API client library to the Contingency Market is now released.

It now caches CM API calls in a MySQL table for 5 minutes (which may also benefit from a MySQL memory cache). Some calls are idempotent and could be cached for longer, but this is not yet supported.

This release has been tweaked for compatibility with PHP v5.2+ and v5.3+.

See contingencymarket.com/Client_APIs for download details.

If anyone’s interested in downloading the MediaWiki extension that uses this API to implement 1p2U.com, that can be uploaded in a jiffy too.

The 0.8 version of the PHP API client library to the Contingency Market is now released.

See contingencymarket.com/Client_APIs for download details.

If anyone’s interested in downloading the MediaWiki extension that uses this API to implement 1p2U.com, that can be uploaded in a jiffy too.

The 0.7 version of the PHP API client library to the Contingency Market is now released.

The primary improvement is locking of MySQL tables as a means of sharing an api session across multiple simultaneous page requests (rather than creating new sessions upon contention).

See contingencymarket.com/Client_APIs for download details.

The 0.5 version of the PHP API client library has now been completely superseded by a 0.6 incarnation embodied within a MediaWiki extension, that enables demonstrations of the API to occur as part of its documentation.

See contingencymarket.com/Client_APIs for download details.

For example the web page that documents the GetEvent() function also displays the result of a call to it when the page is displayed. See contingencymarket.com/GetEvent.