Re: pengines extension to html_requires

I'm sorry you run into problems, surely partly caused by bad
documentation. We'll certainly do our best to write a better one as
soon as possible.

I think we're doing it now!
Certainly your 'story' helps a lot.

So, one way to make a chat room is to make a pengine on browser side
which does an RPC call to some add_chat predicate in a pengine on the server side. (And how does it
know the name of the server's pengine? Presumably the URL is the identifier, but then how is that bound to the server's pengine on the server side?)

add_chat then performs pengine_ask_around with a list of URIs (but the 
browser will not have stable uri? and we must have a list of pengines to
broadcast to, so how is this better than plain ajax?) and calls
show_chat via rpc on the browser's pengine? And how does the servers pengine
collect the list of URL's? And each show_chat fails at end, so we keep trying
and never succeed (which is fine in this case).
Or, when I make a pengine on the browser side, am I acutally creating it on
the server?

Otherwise, is this anything other than wrapping thread_local in some layer of abstraction?

I certainly can see another use case. Suppose I want to do 'family tree' style programming. But usually 'family tree' falls apart on the need to segment the database. For example, we might be playing a multi-player RTS. The game AI is interested in inferring what units might be made. usually in
such games you need to build, say, the 'cartwright' before you can make 'chariots' or 'trade wagons'. So if you see a trade wagon the AI can assume
you may have chariots.
This is all well and good, but the code gets cluttered with the multi-player aspect. I have to carry around a player ID.  Having a pengine for each opposing player solves this.
Now, if I want to simulate ancient armies, where communication was slow and uncertain, I will have a pengine for each 'general', and only the one who saw the wagon will be on the lookout for chariots.
This would have been massively useful with the 'hillpeople' demo in cogbot. We could have segmented what each 'hillperson' knew.
Similar cases abound - a particularly common one, I suppose, is to attach a pengine to an http session. Then we could reason about information in the session, and information in another pengine by rpc call.



And BTW, I would also be interested in knowing if the examples of
interactive programming makes any difference to the ease of
understanding?

I think most of us understand the idea of a virtual process or lightweight process with it's own database and thread.


Can I make a new thread within a pengine? I know they're implemented via thread_local.

Aren't different pengines going to need access to different pieces of code? if I make one pengine that concerns itself with who'se logged on, and another with how much damage weapons do, then I'll have poor encapsulation - the weapons pengine has magically acquired logoff_user, but doesn't have the underlying database information to handle users?