Anyway, between eating lots of stuff many aspects of pipelining were discussed. What's Pipeline.pm all about then? What's the difference between a segment (aka a slot) and a pipeline? In our various models how are we going to link them together? How to we dispatch? What is the store and what can it hold?
pdcawley talked about problems with multiple entry points. It turns out that in some applications you simply need to enter in at a different point in the pipeline, or you need some other form of mechanism that floats around with the session (which is at a higher level than the current store) and allows for dynamic dispatch. This is needed for situations where you have multiple communication channels (e.g. multiple web servers, different irc channels, etc.) I'm sure he'll write a better journal entry discussing this.
Of particular interest to me is the complexity of a store in a pipeline
model (the store is the name for the "thing" that flows through your
pipeline from segment to segment, carrying the data with it.) james
neatly sidesteps the issue by having an abstract store. I, being an
awkward so and so actually want to know how this is going to work
The essential problem as I see it is that you should never throw data away. I always want to be able to access my data later on down the pipeline. This idea is simple, every time you do something you add more data, not take data away. In the standard ->get() and ->set() store this means setting a new key for each item in the pipeline. Once your nice segment has done something to "foo" then it shoves it in "bar". OpenFrame apparently currently does this kind of action by having one of each object type in the store, so that when you move from an Apache::Request to your broken up request (having extracted the data you want) you have it under another key.
The essential problem is this; When I insert a segment into an existing pipeline I want to do two things:
Of course, you can see that these ideas are mutually exclusive. In order to transparently replace data (so that you can later act on it and are none the wiser that a segment in the middle has altered it) you have to do just that - and then you can't access the original data anymore, because you've replaced it! Arrrgh.
My proposed solution to this was that whenever ->set() is called the module stores it under a key and the name of the segment that altered it. This way you can either request the generic version with just the key (in which case you'll get the latest version back) or you can request with the data stored under a key the named segment left. Of course, this isn't a perfect solution (if you do this too much you might want to insert something transparently in the pipeline between those elements, and now you need a third key to disambiguate the data, and so on and so on.) But it's a relatively simple solution that might be good enough.
Of course, if someone can come up with a better solution, let me know...