> I am looking for the point at which I can determine that the inbox and
> outbox communicate via UDP instead of TCP, for example.
> How a protocol is tied to an inbox or an outbox seems vague to me. The
> fact that it "just works" is really nice, but what if I want to change the
> underlying protocol?
...
> I understand this factory syntax. I guess I am thinking of protocols
> incorrectly in Kamaelia, and I want to make sure I get this straight.
> If I wanted to make CleverEchoProtocol() use a different underlying
> protocol, I guess I should not be digging under the hood to find out
> what protocol it uses currently and looking tochange it, but instead
> making another component which speaks the protocol of my choice, and
> pipeline it with this component?
AAh - you are thinking that inboxes and outboxes relate to TCP or UDP
communications? They don't(!)
Inboxes and outboxes have nothing to do with sockets, networking, etc.
They're simply the way one fragment of code in Kamaelia passes data to the
next.
For example, in Object Oriented programming you typically wrap related
fragments of code and data as Objects, then you build your system by
having code in one object call methods on code in another.
In Kamaelia, we try to encapsulate fragments of the system as Components.
And each component works by reading data from its inboxes and writing data
to its outboxes. You then build your system by explaining how you want
these inboxes and outboxes joined together.
In more concrete terms, what is happening under the hood is alot like this:
class FirstComponent:
def __init__(self):
self.outbox = []
def main(self):
while 1:
self.send("a_piece_of_data")
yield 1
def send(self,data):
self.outbox.append(data)
class SecondComponent:
def main(self):
while 1:
if len(self.inbox)>0:
print "Received:",self.recv()
yield 1
def recv(self):
v = self.inbox[0]
del self.inbox[0]
return v
# now we make instances of our two components and
# wire them together:
first = FirstComponent()
second = SecondComponent()
second.inbox = first.outbox
# then we run the two components at the same time
main1 = first.main()
main2 = second.main()
while 1:
main1.next()
main2.next()
You might find it helpful to have a go at working through this short
tutorial Michael made a while ago:
http://www.kamaelia.org/MiniAxon
It takes you through how to build a really simple Axon/Kamaelia system of
your own - thereby showing you what is actually going on.
When a system written using Kamaelia wants to, for example, connect, as a
client, to a TCP port on a server; then we write a component that knows
how to send and receive data on sockets. We write it such that any data it
receives on its inbox will get sent across the TCP socket connection; and
any data it receives will get sent out of its outbox. It just so happens
we've already written one of those - Kamaelia.Internet.TCPClient
Similarly for a server, we write the logic of a server as a component (or
collection of components). In this case
Kamaelia.Chassis.ConnectedServer.ServerCore
> Let's say I need to interface directly with a device, say a serial port
> for example. How do I properly encapsulate this in Kamaelia? Where does
> the driver code get "registered"?
You would write some python code that can send and receive data from a
serial port. You would then make that code into a Kamaelia component, such
that data it receives from the serial port gets sent out of its "outbox"
outbox; and anything that it receives on its "inbox" inbox should get sent
to the serial port.
The component that does this doesn't need to be registered anywhere.
When we talk about "protocols" in Kamaelia - we're talking in the most
abstract sense - a protocol being a behaviour: when we receive X and our
state is Y we send out Z in reply. Your chat protocol you were looking at
before was like this - it doesn't know where the data goes to or comes
from, or how.
The point at which we make that decision (TCP, UDP, serial port, etc) is
when we then come to use that component. Want to make it a protocol used
to handle clients who connect via TCP? We create an instance of
ServerCore, using your chat protocol component as the 'protocol' for it:
ServerCore(protocol=ChatProtocol, port=1501).run()
or:
class ChatProtocolServer(ServerCore):
protocol=ChatProtocol
ChatProtocolServer(port=1501).run()
Want to make a single instance that talks over the serial port? We'd wire
it up to the inboxes and outboxes of our hypothetical serial port handling
component:
class SerialPortTransciever(component):
....
Graphline(
CHAT = ChatProtocol(),
TXRX = SerialPortTransciever(),
linkages = {
("CHAT", "oubox") : ("TXRX", "inbox"),
("TXRX", "oubox") : ("CHAT", "inbox"),
}
).run()
> Sorry if my questions are fuzzy. I am trying to stop thinking in twistd,
> where I had to do some very raw protocol handling in various spots of my
> interface.
> Because of my development history, I am so used to dealing with protocol
> directly that it took me a while to do this paradigm shift.
Its no problem. It is a rather different way to write code to what many
people are used to. I'm really glad you've stuck with it and kept asking
questions - rather than never asking anything and moving onto something
else!
cheers
Matt
--
| Matt Hammond
|
| [anything you like unless it bounces] 'at' matthammond 'dot' org
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
