I got the carousel example working, but it sends/receives from/to the 
original console, not any new client which connects. I realized I can 
reuse the ConsoleEchoer, but somehow make it send a string to a client 
upon connect, and have the server process the string instead of echoing 
it to the server's console.
I tried this, but all proposed solutions so far write to the console, 
not a newly connected client. Maybe I am missing something, btu I think 
I am close.

 Aside from this, I was wondering if a carousel or seq will be 
appropriate to solve my problem.

I am trying to simulate what happens in crude chat systems such as IRC.
For simplicity, in this example the user connects, is prompted for a 
name, and then can chat freely.
If I have two pipelines: one detects client connect and is prompting for 
a name, receiving the response, and then handing control over to another 
pipeline; doesn't this require a disconnect/reconnect with the client? 
If so, this would be bad, because the user would have to re-telnet in, 
would not be "logged in", and would have to start again.

So I guess if I get the data flow working, I can write this logic in one 
pipeline, and reuse the same connection, assuming the first thing a user 
types after connecting would be the name. Or maybe there is a clever way 
to hand off a connected pipline to another utility, so that my flow 
control is cleaner? (not running an "if name is set" check upon each 
message).

Thanks again for your help,
Gloria


>  This is really cool, and exactly what I need. I will get some time 
> later to implement this and try it out, and I am sure I'll have more 
> questions and comments.
> Thanks again for this.
> Gloria
>> On Mar 2, 8:36 pm, Gloria W <strang...@comcast.net> wrote:
>>   
>>> Matt, thanks for this response. It took me a while to get through it and
>>> make sure I understood each point. I appreciate it, comments are below.
>>>     
>>
>> No problem.
>>
>> I've just realised another way to achieve the same effect that is
>> probably simpler!
>>
>> There *is* a component that is all about getting things done in an
>> order: the Seq component (The name is a homage to the OCCAM language):
>>
>>     http://www.kamaelia.org/Components/pydoc/Kamaelia.Chassis.Seq.html
>>
>> With Seq, you provide a list of components. Seq goes through the list,
>> starting with the first component. It activates it and wires up its
>> inboxes and outboxes so that they're mapped to the Seq component's
>> inboxes and outboxes (just like the Carousel does). When that
>> component finishes, it then unwires it and moves onto the next in the
>> list. It therefore effectively runs them *in sequence* one after the
>> other.
>>
>> We've got two steps: displaying the initial message, then taking user
>> input. Both steps need their output to be displayed. So we'll create a
>> Seq componet, Pipeline'd into a console echoer:
>>
>>     from Kamaelia.Chassis.Seq import Seq
>>
>>     Pipeline(
>>         Seq( ... args to be determined! ... ),
>>         ConsoleEchoer()
>>     ).run()
>>
>> We can use a OneShot component (see 
>> http://www.kamaelia.org/Components/pydoc/Kamaelia.Util.OneShot.html
>> ) to send that initial message, so that it gets sent to the
>> ConsoleEchoer and displayed. OneShot, rather conveniently, then
>> immediately terminates; so the Seq component will move onto the next
>> component in its list. That next component can be the Pipeline of a
>> ConsoleReader, sending its output into MyComponent.
>>
>> So what we have is:
>>
>>     from Kamaelia.Chassis.Seq import Seq
>>     from Kamaelia.Util.OneShot import OneShot
>>
>>     Pipeline(
>>         Seq(
>>             OneShot("initial message to be displayed"),
>>             Pipeline(
>>                 ConsoleReader(),
>>                 MyComponent()
>>             )
>>         ),
>>         ConsoleEchoer()
>>     ).run()
>>
>> In this case, MyComponent doesn't need to bother to send the initial
>> message itself, as it did in the suggestion I previously made.
>>
>> So what happens here? Well, when the system starts running, initially
>> the Seq component selects the first item in its list - the OneShot
>> component. So, what actually ends up getting wired up is something
>> like this:
>>
>>     Pipeline(
>>         OneShot("initial message to be displayed"),
>>         ConsoleEchoer()
>>     )
>>
>> Its not actually exactly like that, because the OneShot is still
>> contained within the Seq component - but because all the inboxes and
>> outboxes are mapped to that of the Seq component, it is roughly
>> equivalent.
>>
>> Then when the OneShot component has sent its message and terminated,
>> the Seq component swaps it out and replaces it with the next thing in
>> its list - the pipeline of a ConsoleReader and MyComponent. So the way
>> the system is wired up suddenly switches to something akin to this:
>>
>>     Pipeline(
>>         Pipeline(
>>             ConsoleReader(),
>>             MyComponent()
>>         ),
>>         ConsoleEchoer()
>>     )
>>
>> Again, the inner pipeline is, in reality, contained within the Seq
>> component, but it behaves roughly like it is shown.
>>
>>
>>
>>
>> Matt
>>
>>
>>
>>
>>
>>   
>
>
> >


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"kamaelia" group.
To post to this group, send email to kamaelia@googlegroups.com
To unsubscribe from this group, send email to 
kamaelia+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/kamaelia?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to