Thu Mar 16 11:35:14 2000  MC  <mc@hack.org>

	* INSTALL (New file): Wrote installation notes.

	* README: Changed some text, now describing the system as a proof
	of concept implementation.

	* TODO: Added general ideas and made a point of having standalone
	configuration files.
	
Fri Mar 10 16:21:28 2000  MC  <mc@hack.org>

	* ipp-server.py (New file): A non-forking HTTP server
 	incorporating all the IPP CGIs in its own code written to see if
 	the forking and invokation of Python interpreter is what eats all
 	the response time.

	Added ipp_order().

	Added ipp_approval().
	
	Added ipp-deal().
	
	* seller-server.py (New file): A non-forking HTTP server
 	incorporating all the Seller side CGI scripts in its own code.

	Added seller_order().

	Added seller_deal().
	
	* ipp-server.py (MyHTTPRequestHandler.ipp_order): Took away self
 	references from ipp_order(). Why not use all local variables?

	* perf.py: Rewrote URLs to use the ipp-server code. Ran a few test
 	runs. Each complete transaction now takes ~0.18 seconds (a little
 	less than half the previous timings) with the seller part CGIs
 	still running as true CGIs. This means I was right in assuming
 	forking off the CGIs was where things spent all that time. Even
 	the overhead of the new Python HTTP server (instead of the native
 	Boa) wasn't as expensive as the forking.

	Changed it and ran it again with the new seller-server.py,
 	too. Now, a complete transaction is down to 0.05 seconds.
	
Thu Mar  9 15:06:42 2000  MC  <mc@hack.org>

	* ipp-deal.cgi (form): Couldn't use the IPP module for this, so I
	read the POST form `manually'.

	Gets and parses the response from seller-deal when closing the
 	transaction.

	* seller-deal.cgi (form): Reads OK or Cancel and a tnxid from
 	IPP. Sends back OK or ERROR if we couldn't file it.
	
	* ipp-approval.cgi (order): Added tnxid as a hidden input type in
	the form the consumer approves to.
	
	* seller.py (paymentorder.send): Used httlib to actually contact
	the ipp-order.cgi to file the order and get a tnxid. Strips all
	whitespace for the tnxid that comes back.
	
	* perf.py (payment): Wrote a performance tester acting as the end
 	consumer WWW client going through the steps 1) sending order to
 	the Seller, 2) fetching the approval form from the IPP, and, 3)
 	sending the approval to the IPP. Ran it a couple of times with
 	increasing number of loops. 1000 transactions takes about 10
 	minutes! I blame the forking and the new TCP connections.
	
Wed Mar  8 12:03:17 2000  MC  <mc@hack.org>

	* ipp-deal.cgi (order): Added communication (using httplib) with
 	seller-deal.cgi.

Tue Mar  7 17:01:03 2000  MC  <mc@hack.org>

	* ipp-deal.cgi: Now reads the OK/Cancel choice from the consumer.

	* perf.py (New file): Do a performance test calling
 	seller-order.cgi and answering the following questions
 	automagically, thus behaving like a consumer client. Now POSTs to
 	seller-order.cgi using httplib.
	
Mon Mar  6 17:01:03 2000  MC  <mc@hack.org>

	* seller-order.cgi: Moved most calls to a module (seller.py).

	Calls order.send() to get tnxid (fake for now). Presents a form to
 	consumer to redirect to IPP for approval of transaction
 	(ipp-approval.cgi).

	* seller.py (New file): Most of the methods common for the seller
 	side scripts.
	
	* ipp-approval.cgi: Does the database lookup for the
 	transaction. Presents them (crudely) for the consumer and presents
 	a choice to OK or cancel the transaction in a form that calls
 	ipp-deal.cgi.
	
	* seller.py (paymentorder.fetch): Forgot a cPickle.loads() when
	fetching from the database. Doh.
	
Fri Mar  3 10:56:47 2000  MC  <mc@hack.org>

	* ipp.py: (New file). Moved the class definitions and the methods
 	to a separate file. This makes the ipp.pyc bytecompiled version
	persists between runs and the small CGI scripts import the
	bytecompiled version instead.

	In the class paymentorder, I defined the following methods:
	
  	read(): Reads an entire payment order or possibly just a
 	transaction ID from POST data.

	store(): Stores the payment order in the database.

	fetch(): Fetches the payment order from the database with the
	transaction ID as key.
	
	* ipp-order.cgi: Now uses the paymentorder class in the ipp
 	module. Still has to 
	
	* ipp-approval.cgi: Wrote the glue to read in data. Still needs to
	do the database lookup.
	
Wed Mar  1 10:13:02 2000  MC  <mc@hack.org>

	* seller-order.cgi: Now reads POST data and generates bogus
 	transaction ID returned for test purposes. No contact with IPP
 	yet.

Even earlier MC  <mc@hack.org>
	
	  * seller-order.cgi (New file) takes the form and hands it off to
 	ipp-order.cgi at the IPP. When it returns it takes the trans-id
 	and send back a redirect to the consumer client to
 	http://ipp/ipp-approval.cgi?trans-id

	  * seller-deal.cgi (New file) gets the OK or cancel choice of the
 	consumer from the IPP. If OK, it files the order.

	  * ipp-order.cgi (New file) takes the form and gives it a
 	transaction ID and returns it to the caller (seller-order.cgi). It
 	also stores the data relavant for the transaction to complete.

	  * ipp-approval.cgi (New file) takes the trans-id and presents
 	the deal to the consumer. The choice is sent to ipp-deal.cgi.

	  * ipp-deal.cgi (New file) Should take OK or cancel from the
 	consumer. ipp-deal contacts seller-deal.cgi and tells it about the
 	consumer's choice.
