[PEAK] Connecting the Trellis to non-trellis systems
Phillip J. Eby
pje at telecommunity.com
Tue Mar 11 13:16:27 EDT 2008
At 04:57 PM 3/11/2008 +0100, cheshire at smile.ch wrote:
>Phillip J. Eby a écrit :
>>Looks like the Trellis is going to be able to "untwist" more than
>>just Twisted, in other words.
>Mmh, since you mention Twisted, I'd very much like to see some more
>examples of Trellis used with it.
The code referenced there does a relatively simple hookup, making a
protocol object that maps into two trellis "pipes" for inbound and
outbound socket data. The rest is all implemented on the Trellis
side, as a series of further pipe transformations. I.e. bytes into
messages, messages into events and the creation of other objects, etc.
>(this and SQLAlchemy too...)
>I am curently searching a way to write data transforming rules for
>and ETL that I am writing using Twisted and SQLAlchemy. I am more
>and more convinced that PEAK Trellis is the path to follow, but I am
>still at loss about the where and the when to use it.
Use it whenever things depend on other things that can change and
need to be updated. :) And, once we have the new stuff in place,
you'll also be able to use it wherever you need to subscribe to
callbacks but would rather write code *as if* you were polling. (But
magically only polling when something relevant has actually changed!)
Oh, and also use it when you need components that are loosely coupled
and you want to broadcast certain happenings. For example,
application startup/shutdown, arrival of messages, etc.
Really, it's easier to describe what the Trellis is *not* useful for,
which is to say pure-functional and/or pure-transactional
applications. Web applications, for example, are unlikely to benefit
much from the Trellis except in incidental ways, like using timeouts
to clean up session objects, or to implement connections to outside
systems, or to otherwise manage stateful information either
in-process or via IPC.
Similarly, a program that processes each piece of data only once and
in very linear fashion, and doesn't need data-flow analysis to
determine the order of processing, would likely not benefit much from
In other words, the Trellis is good at connections (e.g. dataflow),
state, and asynchronous I/O. Servers and GUIs usually need to manage
all three, but they're usually not central to the actual process of
generating the average web page. (Doesn't mean you won't have need
for them if you're doing something fancy, of course.)
Of course, that's still a really big area of applicability. :)
There is a certain new twist of thinking required, although
ironically it's a return to simplicity rather than anything new and
complex. It simply requires that you write down the *rules* for what
you would like to have happen, instead of trying to create and manage
the *sequence* of things happening. In the Trellis, sequences in the
large flow from the dependencies between rules, rather than from
trying to pre-determine the order of things. More agile, less BDUF
(Big Design Up Front), in a way.
More information about the PEAK