Thanks for the reply.<div><br></div><div>Very helpful. despite the question being like 'How long is a piece of string'.</div><div><br></div><div>It's good to just hear what someone else reckons is the way to structure the code.</div>
<div><br></div><div>I like the code sample.It makes clearer what some of my options are. So I'll have a look and see how I can make use of it.</div><div><br></div><div>Thanks once again.</div><div><br></div><div>John Aherne</div>
<div><br></div><div><br><br><div class="gmail_quote">On Fri, Jan 2, 2009 at 3:59 PM, Jean-Paul Calderone <span dir="ltr"><<a href="mailto:exarkun@divmod.com">exarkun@divmod.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">On Fri, 2 Jan 2009 10:14:40 +0000, John Aherne <<a href="mailto:johnaherne@rocs.co.uk" target="_blank">johnaherne@rocs.co.uk</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One thing that has been puzzling me is where is the best place to put<br>
application code.<br>
</blockquote>
<br></div>
It depends. :)<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The case I am using is straightforward TCP server with client connections<br>
making simple requests and waiting for responses retrieved from database<br>
tables to be sent back.<br>
<br>
Reading the docs and looking at various examples provided in books and<br>
documentation has left me a bit confused.<br>
<br>
Is there a best practice for where application code should go - either the<br>
protcocol class or the factory class or somewhere else. Does it actually<br>
matter.<br>
<br>
Is there any downside to putting application code in the protocol or<br>
factory. What pitfalls are there for either approach.<br>
</blockquote>
<br></div>
Best practice for a Protocol class is to include code which is necessary<br>
to interpret bytes which are received and turn them into a structured form<br>
which is easier to deal with; code which starts from some structured form<br>
and emits bytes to be sent should also be part of a Protocol class.<br>
<br>
It is common practice to have a class which includes just these things and<br>
then a subclass which adds application-specific logic based on top of this<br>
functionality. It is also common practice to connect a protocol which has<br>
only these things, no application-specific code, and then have application<br>
code elsewhere (in a free function, a method of a factory, another class's<br>
method, user input, etc) make calls onto it. Which of these approaches is<br>
most well suited to a particular application depends. For example, if the application code creates multiple connections with shared state adding the application logic to a Protocol subclass isn't a good approach.<div class="Ih2E3d">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I see examples where application code appears in both classes, but the<br>
examples are very small so may not be indicative of what should be done.<br>
</blockquote>
<br></div>
Generally they're so small that there's no advantage to any approach over<br>
any other, yes.<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the docs I see reference to most of the code will be written in the<br>
protocol class, but that seems to be referring to actually writing protocols<br>
not application code. It also says that when the protocol needs to call<br>
application code to make it a method call - not to mix protocol and<br>
application code. This could just mean creating some methods in the protocol<br>
class to handle the task.<br>
</blockquote>
<br></div>
Consider all of the code you write to be part of a library you're developing.<br>
If you implement a protocol, then you've just written part of a library which<br>
provides a slightly higher-level API for interacting with the network in some<br>
way. With that in hand, you can move on to some other part of your library<br>
which uses that higher-level API to accomplish something even higher-level,<br>
perhaps presenting yet another API to some other part of your application<br>
which is higher-level still. The motivation to not mix protocol and<br>
application code is just the motivation to have clear boundaries in your<br>
library to make as much of it reusable as possible. If you have a protocol<br>
implementation mixed together with application A, when you come along to<br>
write application B which needs to use the same protocol, you'll have to<br>
re-implement the protocol, or refactor your original implementation to move<br>
the application A code elsewhere (of course, there's nothing wrong with<br>
having to refactor your code - it's a common part of programming, and since<br>
it's very difficult to predict the future, it's often best *not* to try to<br>
anticipate your future requirements when writing code - just write what works<br>
and is easily testable, and when your future requirements come along, deal<br>
with them then; as you do this more and more, you'll probably get a sense of<br>
how to structure your code to minimize the effort required for refactoring,<br>
but aside from experience with this process, I don't know of any way to learn<br>
this skill).<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However, if the application code needs to run for 10-12 seconds looking up<br>
database tables and accumulating results and waiting on deferreds, should<br>
all this code reside in the protocol class or the factory.<br>
</blockquote>
<br></div>
I wouldn't take the duration of the task into consideration when trying to<br>
decide where to put it. I'd consider reusability, testability, simplicity,<br>
and correctness.<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If I keep it in the protocol, then I already have my client connection to<br>
write back to. So that seems to be the place to keep the code.<br>
<br>
If I put the code in the factory, then I need to pass the client connection<br>
so it can write back to the client. Or is there another way of doing this I<br>
have missed.<br>
</blockquote>
<br></div>
This isn't much different from the trade-off you have to consider when you<br>
decide to implement anything as two classes instead of one. Since you can<br>
no longer just use `self´ everywhere, you'll have to figure out how to get<br>
a reference to the other instance that you need sometimes. This shouldn't<br>
be difficult though - just invoke a method on one class with an instance of<br>
the other.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
.<div class="Ih2E3d"><br>
The factory seems to be the place where other classes can be passed in and<br>
the protocol can call them via self.factory. That seems to imply that<br>
application code should be put into the factory, but I can't see any way of<br>
passing back information from deferred results to the call from protocol.<br>
It's ok if it was just a simple method call that returns a result, but if<br>
the code has to run a series of deferreds then it will be the called method<br>
that will have the result and it will need a means of writing this back to<br>
the client. I don't think I can signal the protocol to say I now have the<br>
result.Of course I could easily be mistaken. So please correct.<br>
</div></blockquote>
<br>
This is just what Deferreds are for. For example, let's consider a protocol<br>
and factory for a game server lobby. The protocol has a message type which<br>
lets the server inform the client of the list of games which are currently<br>
available to be joined. The Protocol subclass sends this information to<br>
the client when the connection is established, but it uses the factory<br>
to actually find the list of games that are available. Again, this<br>
division is probably desirable for a number of reasons (it simplifies<br>
unit testing, for example).<br>
<br>
class GameFactory(ServerFactory):<br>
def availableGames(self):<br>
"""<br>
Return a Deferred which will fire with a list of the games<br>
currently available to be joined.<br>
"""<br>
return self.connectionPool.runQuery(<br>
"SELECT game_id FROM available_games")<br>
<br>
<br>
class GameProtocol(Protocol):<br>
def connectionMade(self):<br>
"""<br>
Send the available-games message so the client can pick one to<br>
join.<br>
"""<br>
d = self.factory.availableGames()<br>
def cbGotGames(games):<br>
self.transport.write(" ".join(games))<br>
d.addCallback(cbGotGames)<br>
d.addErrback(log.err)<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Of course if I passs the client connection to the factory, then it can use<br>
this to write back. But that means passing around the client connection.<br>
Should I avoid doing that or is that not a problem.<br>
</blockquote>
<br></div>
It's an option, but I hope the above example will show how you can use<br>
Deferreds to avoid needing to do this.<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I hope I have explained myself clearly. I'm just looking for some guidance<br>
and pointers to what is best to do or what is best to avoid.<br>
<br>
</blockquote>
<br></div>
Hope this helps,<br>
<br>
Jean-Paul<br>
<br>
_______________________________________________<br>
Twisted-Python mailing list<br>
<a href="mailto:Twisted-Python@twistedmatrix.com" target="_blank">Twisted-Python@twistedmatrix.com</a><br>
<a href="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python" target="_blank">http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python</a><br>
</blockquote></div><br></div>