[PEAK] Connecting the Trellis to non-trellis systems

[Phillip J. Eby]

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.

http://www.eby-sarna.com/pipermail/peak/2008-March/002888.html

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 
the Trellis.

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.