Subject: OCP Core version head_sid8 available

From: Alex Rousskov <[email-masked]>
Date: Wed, 28 May 2003 20:33:22 -0600 (MDT)

The [major] change log is quoted below. The latest snapshot, including
XML sources for those doing hands-on modifications, is available at

	http://www.measurement-factory.com/tmp/opes/

Please continue to comment and work on the to-do list. Personally, I
plan to add negotiation-specific messages next, based on a summary
posted to this list two weeks or so ago.

Thank you,

Alex.

-------------- change log ----------------

head-sid8

  *  Added structure and list values to ABNF syntax.

  *  Messages with multiple equally-named parameters are
     semantically invalid.

  *  Added types for message parameters.

  *  Started replacing complicated, error-prone, and probably mostly
     useless "modified" parameter with a clear and simple "as-is"
     parameter.

  *  Converted parameter descriptions from list items to
     subsections.

  *  OCP syntax requires one or two character lookups to determine
     the next message part. Fixed a comment for implementors saying
     that one lookup is always sufficient.

---

From: "Martin Stecher" <[email-masked]>
Date: Fri, 30 May 2003 23:07:16 +0200

> 
> > - break
> >
> [...]
>
> Personally, I favor option 2. I think there was some discussion about
> this already. Please see the noisy "copying commitment and deadlock"
> thread around March 24th and 25th. Here is a gist of what seemed as a
> good solution at that time:
> 
> 	- To get out of the loop early, a callout server
> 	  sends a i-want-out message to the processor
> 
> 	- To let a callout server out of the loop,
> 	  the processor must send xaction-end message
> 	  to the server
> 
> 	- A callout server cannot get out of the loop
> 	  nicely until it receives a xaction-end message
> 
> The above scheme is simple and deadlock free. Note that it does not
> rely on processor supporting copying of data; there is no copying
> commitment involved. The scheme is efficient unless there are a lot of
> unprocessed messages buffered between the processor and the server. To
> increase efficiency, a more complex scheme with priority communication
> channels would be required (to bypass a long chain of unprocessed
> messages).
> 
> Would you like us to proceed with this i-want-out/xaction-end scheme?

Thank you for carrying this out again.
I now agree that this seems to be the best option.

Martin