Hi Phillip,<br><br>Are there any GUI examples? wxPython examples would be ideal. :)<br><br>Thank you.<br><br>Peter.<br><br><br><div class="gmail_quote">On Tue, Mar 11, 2008 at 3:05 AM, Phillip J. Eby <<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">There are two types of connections to non-trellis systems I'd like to<br>
talk about for a bit: connections to callback-based systems, and<br>
connections to "pure imperative" systems. For example, connecting to<br>
a socket using Twisted or receiving wxPython GUI events might be an<br>
example of the first kind of system, and connecting to a database via<br>
SQLAlchemy or controlling Ecco via DDE would be examples of the second.<br>
<br>
The catch with the first kind of system is that in the Trellis, we<br>
don't like callbacks. :) More specifically, we don't like having to<br>
explicitly register them. What we really want is to just do<br>
something like 'is_readable(socket)' in a rule, and have the<br>
callbacks automatically get set up -- and automatically disconnected<br>
when they're not needed.<br>
<br>
One crude way of doing this is already implemented in Trellis "Time"<br>
rules. There's a weak dictionary that discards the timed event cells<br>
if they are no longer being referenced. This is fine for Trellis<br>
time events, as they don't have any reference cycles and the Trellis<br>
ignores discarded events.<br>
<br>
But, for more complex applications, there can be undesirable<br>
consequences for leaving subscriptions in effect when they are not<br>
being used. For example, consider the consequences of say, capturing<br>
the mouse in a particular window, and not releasing it! (i.e.,<br>
imagine you could have a cell like 'captured_mouse_position', and<br>
capture the mouse as a side effect of depending on its value).<br>
<br>
(Also, when interacting with an external system, unless special<br>
precautions are taken, the callback from that system is going to have<br>
a reference to the target cell... meaning it won't be able to be<br>
garbage collected, and thus won't be able to rely on getting<br>
automatically cleaned up.)<br>
<br>
So, we really need an easy way to make or break callback arrangements<br>
when a cell gains -- or loses -- subscribers. Perhaps a specialized<br>
cell type that's easily customized (either per-instance or<br>
per-subclass) to do the right sort of callback-making and callback-breaking.<br>
<br>
The second kind of interfacing is a bit different. Instead of<br>
wanting to receive input via callbacks from the outside world, we<br>
want to simply *wrap* an externally-supplied data value, passing both<br>
reads and writes through to the underlying system (maybe with some<br>
caching), but notifying other cells when the value is changed.<br>
<br>
Generally, these external systems may be costly to retrieve data<br>
from, so we probably want them to be "optional" attributes, i.e., not<br>
initialized until/unless you read their values. Costly retrieval<br>
also implies that we may want to cache the read value, rather than<br>
passing through every read.<br>
<br>
In fact, even if retrieval isn't costly, we *still* need to do<br>
caching, because within a given trellis recalculation, a cell's value<br>
is supposed to be stable. It can't just go changing on its own.<br>
<br>
If we're connecting to a system where values *can* change on the fly,<br>
but does not offer notification callbacks, then we may need some way<br>
to use a "time to live" (TTL) before the value is automatically<br>
refreshed. And we can provide an explicit refresh operation as a @modifier.<br>
<br>
Having the cached value is also handy for writes; we can compare the<br>
cached value to the written value in order to decide whether to pass<br>
on the write to the underlying system.<br>
<br>
It seems like it might be possible to create a single cell type that<br>
handles all of these use cases. There could be methods like:<br>
<br>
_poll() -> return the current value from the outside system<br>
_send(value) -> send the value to the outside system<br>
_receive(value) -> receive a value from a callback<br>
<br>
_subscribe() -> arrange for _receive() to be called on changes<br>
_unsubscribe() -> stop calling _receive()<br>
<br>
refresh() -> self._receive(self._poll())<br>
<br>
With the exception of _receive(), and refresh(), these methods would<br>
be specific to the type of thing being interfaced with. When the<br>
cell is uninitialized -- or if its TTL has expired -- reading its<br>
value would do a refresh() first, before reading the cached value.<br>
<br>
Whenever the cell is written with a changed value, it would pass the<br>
value through to _send(), as soon as the current recalculation was<br>
completed. And when listeners are added or removed from the cell, it<br>
would make sure to arrange for the appropriate _subscribe() or<br>
_unsubscribe() operation to occur when the current recalculation commits.<br>
<br>
In practice, it will probably be best to have two cell types: one for<br>
a read-only connections, and one for read-write connections. For<br>
SQLAlchemy integration, we'll take the read-write version and set it<br>
up to talk through a delegated descriptor. (Which will be an<br>
interesting sub-project in itself, I suspect.)<br>
<br>
TTL is also an interesting subproject. If reading the cell value<br>
checks the TTL using the standard Time service, then any rule that<br>
reads the cell will also implicitly depend on the TTL and be<br>
refreshed when the TTL expires. In some respects this is reasonable<br>
and perhaps even desirable, except that it will cause rules to be<br>
re-run even when the value hasn't changed. Perhaps it would be<br>
better to make the TTL system a part of the subscribe/unsubscribe<br>
mechanism, such that refresh() is called when the TTL expires, if and<br>
only if there are listeners still looking for the value.<br>
<br>
Yes, that seems to make more sense. In fact, if this cell type is a<br>
variation of the standard rule+value cell type, then it's even<br>
easier. The rule will simply amount to something like:<br>
<br>
if ttl_has_expired:<br>
reset the ttl<br>
return _poll()<br>
<br>
So that could work pretty decently, I think. What's rather<br>
interesting about this is that it would make it *really* easy to<br>
interface to systems that have to be polled, such as inter-thread<br>
queues, filesystem directory contents, and so forth. We could even<br>
have an API function like "sense(interval, func, *args)" so you could<br>
do something like::<br>
<br>
if trellis.sense(10, os.path.isfile, some_file):<br>
...<br>
<br>
in a rule, so as to automatically detect when some_file is created,<br>
checking every 10 seconds. (The function would similar to the Time<br>
service, i.e., by referring to a service that holds cells in a weak<br>
value dictionary, keyed by the interval, function, and function<br>
arguments. Thus, the same cell would be reused by any/every rule<br>
that's polling for the same thing.)<br>
<br>
So, I'm thinking that the two cell types we need could be called a<br>
Sensor (read-only) and an Effector (read-write). The only difference<br>
between the two would be that an Effector would be writable, and<br>
would need a _send() method. (Well, and Effector would probably mix<br>
in different classes to get write behavior, but that's an<br>
implementation detail.)<br>
<br>
[insert **long** delay while I sketch lots of code for hours on end...]<br>
<br>
So, I think I've got this figured out now. Sensor and Effector will<br>
be generic cell types, and the standard Cell() constructor will be<br>
enhanced to automatically create them if needed. There will be a<br>
'writer' keyword you can use to supply a 'write(value)' function, and<br>
if specified it will make your cell an Effector.<br>
<br>
To implement subscription-based rules, you'll be able to subclass a<br>
base called AbstractConnector, implementing read(), subscribe(cell)<br>
and unsubscribe(cell, key) methods. Using such a rule will make your<br>
cell a Sensor (unless you also specify a writer, in which case you'll<br>
get an Effector). You'll also be able to use<br>
Connector(read,sub,unsub) to create a connector from three functions,<br>
without needing to make a subclass.<br>
<br>
The net result, once I do the implementation and testing, should be<br>
that connecting to read-only outside data sources will require only<br>
making appropriate connectors, or using a polling factory to wrap the<br>
rule. Connecting a writer to a data source will require only that<br>
the write function be known.<br>
<br>
There may also need to be some changes to the high-level API to allow<br>
specifying this sort of thing for rules in a class body. More<br>
likely, however, connectors will get managed via services or explicit<br>
cell creation and manipulation.<br>
<br>
For example, it's likely that testing a socket's readability or<br>
writability will occur through an API, rather than by having a cell<br>
attribute tied directly to this. These APIs will simply create the<br>
appropriate cell and read its value, caching the cell according to<br>
its creation parameters (e.g., by using an add-on, or a weak<br>
dictionary). For example, a socket management service would probably<br>
cache such cells by fileno(), while for a wx event listener, there<br>
would probably be a cache of cells by event ID attached as an add-on<br>
to the target window or other object. Querying for these events is<br>
then reduced to a dictionary lookup followed by a .value access in<br>
the common case.<br>
<br>
Whew! I think that's more than enough for today. :)<br>
<br>
_______________________________________________<br>
PEAK mailing list<br>
<a href="mailto:PEAK@eby-sarna.com">PEAK@eby-sarna.com</a><br>
<a href="http://www.eby-sarna.com/mailman/listinfo/peak" target="_blank">http://www.eby-sarna.com/mailman/listinfo/peak</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>There is NO FATE, we are the creators.