MixinPipeline, or more generally ideas for structuring pipelines.

["Trustin Lee (이희승)"]

A similar idea from another user:

  http://is.gd/9WgRh

rzo wrote:
> Hi,
> 
> concerning handling of downstream events coming from multiple pipelines:
> I suppose we should forward all of them in incoming order.
> 
> changing bootstrap is just an idea. this could also be done on the pipeline.
> that is pipeline or maybe pipeline factory could implement the composite
> pattern.
> (http://en.wikipedia.org/wiki/Composite_pattern)
> Currently the problem that I have with pipeline is that the only 
> pipeline implementation is
> attached to a channel and a sink. For composite pattern to work I must
> be able to create a pipeline
> which is independent of a channel and then add it to a
> DefaultChannelPipeline. I must be able to remove it from
> a "channeled" pipeline and add it to another pipeline.
> 
> My idea is to have a class:
> 
> class ChannelLessPipeline implements  ChannelPipeline
> 
> That is a pipline where getChannel returns null.
> 
> and the methods:
> 
> ChannelPipeline.addxxx(ChannelPipeline)
> 
> xxx == First, Last, Before, ....
> 
> ChannelPipeline.remove(ChannelPipeline)
> 
> ChannelPipeline.getPipeline(String pipelineName)
> ChannelPipeline.removePipeline(String pipelineName)
> 
> ChannelPipeline.set/getName(String)
> 
> ChannelPipeline.get("channelName/handlerName")
> 
> 
> Using the composite will make it easier to use building blocks.
> For example we could have an HttpPipeline which contains the http
> encoder/decoder/chunck... implemented within a web server project.
> We could use this within a webdav pipeline. or within a jaxta pipeline.
> 
> 
> Concerning parallel pipelines. what I mean is not parallel in the sense
> of threading but in the sense of event flow.
> For this one could foresee a pipline implementation:
> 
> ParallelChannelPipeline
> 
> where the add method adds in parallel and not in sequence.
> 
> Thus a handler could always get the original ChannelBuffer by sending it
> on a parallel pipeline which has a handler which just stores it.
> (similar to a rail holding track)
> If a handler requires the buffer it could access this holding track.
> This could be used not just for the incoming buffer but for any message
> sent through the pipeline.
> 
> Be aware that this are just preliminary ideas.
> 
> I have implemented something similar to composite pattern within my
> async hessian patch.
> 
> org.rzo.netty.ahessian.session.MixinPipeline
> 
> take a look at and its usage. This may make things clearer.
> 
> The current implementation avoids changing the netty implementation.
> However it would be "nicer" if netty provided built-in pipeline composition.
> 
> The idea, in async hessian is that whenever a client joins his session
> the client's previous pipeline is added to the pipeline of the channel.
> The client can thus disconnect and reconnect multiple times and will
> always find the same "partial" pipeline (therefore state) on the server.
> When the sub-pipeline is removed it is "detached" from the channel. When
> it is added to a new pipeline it is "attached" to its channel.
> 
> Concerning your proposal to subversion the hessian implementation: That
> would be great. I hope to find someone to review the code.
> Do you have a proposal for the package name ?
> 
> -- Ron
> 
> 
> 
> On 25.01.2010 10:17, "Trustin Lee (이희승)" wrote:
>> Hello Ron,
>>
>> If a pipeline is parallelized, how do we determine which event from
>> multiple sub-pipelines should be forwarded to the next joined pipeline?
>>
>> What about implementing it as a separate ChannelPipeline implementation
>> instead of modifying Bootstrap?
>>
>> Thanks for a cool idea!
>> Trustin
>>
>> rzo wrote:
>>   
>>> Hello,
>>>
>>> with this post I would like to initiate a discussion on enhancements for 
>>> pipeline.
>>>
>>> Within my asynch hessian patch I have implemented a "MixinPipeline".
>>> That is an implementation of a Pipeline, which allows to insert a 
>>> pipeline or remove a pipeline
>>> to/from an existing pipeline.
>>>
>>> Another idea I had for the "WAF" example which I posted was to implement 
>>> "parallel" pipelines.
>>> eg the ability to send an incoming buffer along multiple parallel 
>>> pipelines, synchronize their processing, etc.
>>>
>>> I think that implementing generic methods/classes for this kind of 
>>> operations would be great and will enable
>>> to use building blocks within netty. It will also enable to use existing 
>>> pipeline factories from other applications by
>>> just combining them. Something in the line of:
>>>
>>> bootstrap.addLastPipelineFactory("httpTunnelServerPipeline", ...)
>>> bootstrap.addParallelPipelineFactory("httpTunnelServerPipeline", 
>>> "wafPipeline", ...)
>>> bootstrap.addLastPipelineFactory("asycHessianServerPipeline", ...)
>>>
>>> What do you think ?
>>>
>>> -- Ron
>>>
>>>
>>>
>>> _______________________________________________
>>> netty-users mailing list
>>> netty-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>     
>>   
>>
>>
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users

-- 
what we call human nature in actuality is human habit
http://gleamynode.net/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20100308/b2112eb8/attachment.bin