Gmail Calendar Documents Reader Web more »
Recently Visited Groups | Help | Sign in
Google Groups Home
Kamaelia AWS
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  8 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Ben Ford  
View profile  
 More options Oct 14 2008, 12:31 pm
From: "Ben Ford" <ben.for...@gmail.com>
Date: Tue, 14 Oct 2008 17:31:08 +0100
Local: Tues, Oct 14 2008 12:31 pm
Subject: Kamaelia AWS

Hi all,

I've set up a googlecode project with access to the code I've written to
interact with Amazon Web Services here:
http://code.google.com/p/kamaelia-aws/. I've set up source control here:
http://freehg.org/u/ben/kamaelia-aws/.

It's my first time using kamaelia so I'd love to hear any feedback on the
code. Feel free to use it, and let me know what you think.

--
Regards,
Ben Ford
ben.for...@gmail.com
+447792598685


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Michael Sparks  
View profile  
 More options Oct 15 2008, 4:54 am
From: Michael Sparks <spark...@gmail.com>
Date: Wed, 15 Oct 2008 01:54:51 -0700 (PDT)
Local: Wed, Oct 15 2008 4:54 am
Subject: Re: Kamaelia AWS
Hi Ben,

On Oct 14, 5:31 pm, "Ben Ford" <ben.for...@gmail.com> wrote:

> Hi all,

> I've set up a googlecode project with access to the code I've written to
> interact with Amazon Web Services here:http://code.google.com/p/kamaelia-aws/.
> I've set up source control here:http://freehg.org/u/ben/kamaelia-aws/.

This is very much appreciated. I've taken a quick look and it looks
interesting/useful.

> It's my first time using kamaelia so I'd love to hear any feedback on the
> code. Feel free to use it, and let me know what you think.

There's some areas which I'll comment on, since the minor changes I'll
suggest will
make the components more general & useful :-) This may mean minor
changes to some
arguments, but if that's a problem I have a clean way of managing
that :-)

I'd like to target this into the 0.7.0 release, due mid november
(assuming no major issues
of course :-).

Many thanks & best regards,

Michael.


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Sylvain Hellegouarch  
View profile  
 More options Oct 15 2008, 3:45 pm
From: Sylvain Hellegouarch <s...@defuze.org>
Date: Wed, 15 Oct 2008 21:45:18 +0200
Local: Wed, Oct 15 2008 3:45 pm
Subject: Re: [kamaelia-list] Kamaelia AWS
Hi Ben,

> Hi all,

> I've set up a googlecode project with access to the code I've written
> to interact with Amazon Web Services here:  
> http://code.google.com/p/kamaelia-aws/. I've set up source control
> here: http://freehg.org/u/ben/kamaelia-aws/.

> It's my first time using kamaelia so I'd love to hear any feedback on
> the code. Feel free to use it, and let me know what you think.

It's pretty cool. I've long believed it would be a cool project. I had
not given more thoughts because I was busy elsewhere.

I've skimmed through your code and it's clean. However I have a comment
regarding your use of boto. I have nothing against it but IMO:

* it's slower than it should due to all the internal XML work they do
(and to be fair not the easiest to follow)
* you're not benefiting from Kamaelia to its fullest

I had worked on a queue system last year based on Kamaelia and I had
started working on integrating it with SQS. You may want take a look at
it to see what I mean:

https://svn.defuze.org/oss/bucker/bucker/provider/sqs.py

The idea was to register a component in charge of parsing/serializing
XML and then pushing it to another component that would interpret said
XML message.

I don't think you actually need boto.

- Sylvain


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Ben Ford  
View profile  
 More options Oct 15 2008, 5:47 pm
From: "Ben Ford" <ben.for...@gmail.com>
Date: Wed, 15 Oct 2008 22:47:45 +0100
Local: Wed, Oct 15 2008 5:47 pm
Subject: Re: [kamaelia-list] Re: Kamaelia AWS

Hi Sylvain,

I never thought of using bucker like that... BTW, the logger is pretty much
stolen from bucker, so thanks! ;-)

I just picked boto because it's the de-facto way for python to talk to AWS,
not out of any real preference, so I'd be happy to see the code ported to
something better.

Your implementation looks a lot more comprehensive than mine, could you
explain what you mean by "you're not benefiting from Kamaelia to its
fullest"..? Part of the reason for releasing this was to get an idea of how
well aligned what I've written is to Kamaelia, and Michael alluded to a few
improvements too, so I'd be really interested to know how to improve it!

I forgot to mention on the google code project that you'll need to apply the
patch in the root of the project to boto for the json messages to work
properly.

Cheers,
Ben

2008/10/15 Sylvain Hellegouarch <s...@defuze.org>

--
Regards,
Ben Ford
ben.for...@gmail.com
+447792598685

    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Sylvain Hellegouarch  
View profile  
 More options Oct 16 2008, 9:18 am
From: "Sylvain Hellegouarch" <s...@defuze.org>
Date: Thu, 16 Oct 2008 15:18:34 +0200 (CEST)
Local: Thurs, Oct 16 2008 9:18 am
Subject: Re: [kamaelia-list] Re: Kamaelia AWS
Hi Ben,

> Hi Sylvain,

> I never thought of using bucker like that... BTW, the logger is pretty
> much
> stolen from bucker, so thanks! ;-)

That's what BSD is for ;)

> I just picked boto because it's the de-facto way for python to talk to
> AWS,
> not out of any real preference, so I'd be happy to see the code ported to
> something better.

I don't want to sound harsh about boto because it has great
functionalities and works actually well. I'm less convinced by the
internal implementation and I believe it suffers from a lack of large
refactoring. Anyway the choice was rather obvious and the right one.

> Your implementation looks a lot more comprehensive than mine, could you
> explain what you mean by "you're not benefiting from Kamaelia to its
> fullest"..? Part of the reason for releasing this was to get an idea of
> how
> well aligned what I've written is to Kamaelia, and Michael alluded to a
> few
> improvements too, so I'd be really interested to know how to improve it!

Basically to make the best of Kamaelia, actually Axon but let's generalise
to Kamaelia, you have to consider every functionality as its own
microprocess (the Axon microprocess). Then you can indeed decide whether
it is worth writing it as a component per se or wrap an existing library
into said component as you do here.

I realise now that my comment was harsher than meant. If you feel like
there is no added value for you to implement what boto does (basically
parsing AWS XML messages in and out) you are indeed just fine and no need
to change anything. However you might consider that doing so could bring
your greater flexibility or control. It's really a case of "Would it bring
more value?"

With bucker I chose not to use boto because I thought it didn't suit the
design I had in my head very well and I didn't want the dependency. So I
chose to encapsulate my XML parser [1] into a component. Indeed "bridge"
has the nice feature of dispatching elements based on some conditions
(typically a qnamed element closed) which integrated well with the flow of
how Axon works (I/O).

Note that I've made a choice of not using the built-in XML parser Kamaelia
offers as it wouldn't give me the same possibilities. Like you I've made a
choice at some point that non-Axon based library were better encapsulated
into components to interface them. I just did it at a lower level than
you.

Note also that I could have written a simpler API for the SQSQueue class
considering that the client is always driving the SQS request. Unlike XMPP
where a message can be pushed to you, with HTTP you ask for it so there is
no real rational in dispatching when a response arrive as I did... I'm not
reacting to something unexpected. Hmmm... while writing this I actually
remember that one potential reason for this decision was the architecture
I had designed... but this is blurred in my mind.

That code is more than a year old and it also shows some of my lack of
experience with Axon and Kamaelia. I'd probably do things differently now.

- Sylvain

--
Sylvain Hellegouarch
http://www.defuze.org


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Michael Sparks  
View profile  
 More options Oct 17 2008, 1:03 pm
From: Michael Sparks <spark...@gmail.com>
Date: Fri, 17 Oct 2008 18:03:59 +0100
Local: Fri, Oct 17 2008 1:03 pm
Subject: Re: [kamaelia-list] Re: Kamaelia AWS
On Wednesday 15 October 2008 22:47:45 Ben Ford wrote:

> Michael alluded to a few
> improvements too, so I'd be really interested to know how to improve it!

I'm planning on discussing these this evening, but the thing that jumped out
at me most when I was that it's missing some of the newer idioms that we use
(which isn't too surprising). I want to do a proper code review since I'd
like to get this merged, and I want to do that after doing the Axon 1.6
release notes (which are in progress). However I think it's useful to give a
very quick example of what I mean here.

Take this example from kamaelia-aws/aws/sqs.py :

CONTINUE_MSG = "CONTINUE"

class Ticker(threadedcomponent):
    """A Component that sends out a message to wake up an asleep component"""

    def __init__(self, timeout=5):
        """Initialize the component with a timeout

        :param timeout: The time in second to wait for
        :type timeout: int
        """
        super(Ticker, self).__init__()
        self.timeout = timeout

    def __str__(self):
        return u"Ticker: %s secs" % self.timeout

    def main(self):
        while 1:
            time.sleep(self.timeout)
            self.send(CONTINUE_MSG, "signal")

This boils down to: (skipping docs and __str__)

CONTINUE_MSG = "CONTINUE"

class Ticker(threadedcomponent):

    def __init__(self, timeout=5):
        super(Ticker, self).__init__()
        self.timeout = timeout

    def main(self):
        while 1:
            time.sleep(self.timeout)
            self.send(CONTINUE_MSG, "signal")

This isn't as general as it could be, it would be nice to do this:

class Ticker(threadedcomponent):

    def __init__(self, timeout=5, message=CONTINUE_MSG):
        super(Ticker, self).__init__()
        self.timeout = timeout
        self.message = message

    def main(self):
        while 1:
            time.sleep(self.timeout)
            self.send(self.message, "signal")

Since that makes the component generic. However the signature of
Component.__init__ these days is Component.__init__(self, **argd).

The reason for that is because the signature of
Microprocess.__init__ these days is Microprocess.__init__(self, **argd).

And the reason for that is so that Microprocess.__init__ can do this:
    self.__dict__.update(argd)

This means that you can specify defaults like this:

class Ticker(threadedcomponent):
    timeout = 5
    message = CONTINUE_MSG

    def main(self):
        while 1:
            time.sleep(self.timeout)
            self.send(self.message, "signal")

And still override self.timeout or self.message with local defaults like this:
   Ticker(timeout=5, message=5)

When you first do this it feels very strange, but you then start to realise
huge advantages. For example, the ServerCore does this:

(http://kamaelia.googlecode.com/svn/trunk/Code/Python/Kamaelia/Kamaeli...)

from Kamaelia.Internet.TCPServer import TCPServer

class ServerCore(Axon.AdaptiveCommsComponent.AdaptiveCommsComponent):
    port = 1601
    protocol = None
    socketOptions=None
    TCPS=TCPServer

Now the fun part here is TCPS/TCPServer, since this gets used later on like
this:

if self.socketOptions is None:
    self.server = (self.TCPS)(listenport=self.port)
else:
    self.server = (self.TCPS)(listenport=self.port,
                                       socketOptions=self.socketOptions)

This means that someone can come in and override TCPS themselves later on -
which has obvious advantages when it comes to mock based testing. However,
TCPServer does the same thing:
(http://kamaelia.googlecode.com/svn/trunk/Code/Python/Kamaelia/Kamaeli...)

from Kamaelia.Internet.ConnectedSocketAdapter import ConnectedSocketAdapter

class TCPServer(Axon.Component.component):
   CSA = ConnectedSocketAdapter

...
   def createConnectedSocket(self, sock):
...
      CSA = (self.CSA)(newsock,self.selectorService)

On the surface of things, this only makes testing easier, but it actually
allows complete repurposing. For example if you had UDP server that could
look like TCPServer/CSA in the behaviour it has regarding inboxes/outboxes &
handling of data, then you could do this:

class UDPServerCore(ServerCore):
    port = 1601
    protocol = None
    socketOptions=None
    TCPS=UDPServer

If you wanted to create an echo protocol server based on this change you could
do this directly as follows:

class EchoUDPServerCore(ServerCore):
    port = 1601
    protocol = None
    socketOptions=None
    TCPS=UDPServer
    class protocol(Axon.Component.component):
        def main(self):
            while not self.dataReady("control"):
                for d in self.Inbox("inbox"):
                    self.send(d, "outbox")
                if not self.anyReady():
                    self.pause()
                yield 1

Or you could write it:

class echoer(Axon.Component.component):
    def main(self):
        while not self.dataReady("control"):
            for d in self.Inbox("inbox"):
                self.send(d, "outbox")
            if not self.anyReady():
                self.pause()
            yield 1

class EchoUDPServerCore(ServerCore):
    port = 1601
    protocol = None
    socketOptions=None
    TCPS=UDPServer
    protocol = echoer

However it also allows more complex arrangements like this:

class GreylistServer(ServerCore):
    logfile = config["greylist_log"]
    debuglogfile = config["greylist_debuglog"]
    socketOptions=(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    port = config["port"]
    class TCPS(TCPServer):
        CSA = NoActivityTimeout(ConnectedSocketAdapter,
                                       timeout=config["inactivity_timeout"],
                                       debug=False)
    class protocol(GreyListingPolicy):
        servername = config["servername"]
        serverid = config["serverid"]
        smtp_ip = config["smtp_ip"]
        smtp_port = config["smtp_port"]
        allowed_senders = config["allowed_senders"]
        allowed_sender_nets = config["allowed_sender_nets"]
        allowed_domains = config["allowed_domains"]
        whitelisted_triples = config["whitelisted_triples"]
        whitelisted_nonstandard_triples = config["whitel... "]

ie it allows someone to be able to go "Hmm, what I want is more or less
that code, but with this component configured in this way, rather than what
it does right now". This won't always be correct for every case by a long
shot, but it does open up all sorts of possibilities... (Primarily it makes it
easier to write something simple once and then allow people to use it to
make more complex systems :)

Michael.
--
http://www.kamaelia.org/Home


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Ben Ford  
View profile  
 More options Oct 17 2008, 1:47 pm
From: "Ben Ford" <ben.for...@gmail.com>
Date: Fri, 17 Oct 2008 18:47:05 +0100
Local: Fri, Oct 17 2008 1:47 pm
Subject: Re: [kamaelia-list] Re: Kamaelia AWS

Ah ha I see.

I haven't come across the technique of using kwargs to override attributes
set on the class before, it seems like a nice way to avoid needless
subclassing and __init__ overriding. On the flip side,  I'd also say that
it's got a lot of potential to trip you up, and would make the code harder
to understand if you didn't write it yourself... That doesn't necessarily
make it a bad idea, but I wouldn't have thought to do it that way, and
likewise without the explanation I would have spent quite a while figuring
out what was going on. This kind of thing may be part of the reason that
experienced python developers find Kamaelia a little hard to get started on?

if self.socketOptions is None:

>    self.server = (self.TCPS)(listenport=self.port)

I haven't seen this before either, why do you have the brackets around the
TCPS class?

These techniques are great, but they're also quite unusual... I'd comment
that style/implementation decisions like this  in the Kamaelia codebase
would be a great place for a tutorial, and an explanation of the rationale
behind them.

On the documentation side of things, what did you think of Sphinx? One of
the other things that has added slightly to my overhead in groking Kamaelia
is navigating the (online) documents and having the docs inline in the
module docstring: Most of the time when I open a python source code file, I
actually want to get straight to the code, and most python source I've does
indeed have the source code right there at the top of the file. I really
like that sphinx gives you such a comprehensive index and great navigation.

Based on our work with Kamaelia in building this AWS stuff, I have a couple
of suggestions. These may or may not be good suggestions and I'm quite
prepared to accept judgment either way. They might equally be purely
personal idiosyncrasies ;-)

I find the Kamaelia code structure to be a bit too "split up", I'd advocate
not having one module for each class called the same thing, I much rather
see:
from kamelia.chassis import GraphLine, Pipeline, Carousel
than:
from Kamaelia.Chassis.Graphline import Graphline et al
* (even if the above is achieved using a bunch of imports in __init__ files)

I'd like to see Sphinx used as a documentation tool, it ROCKS seriously!

I think critiques like this are really valuable, both personally to new
programmers who've just written their first Kamaelia stuff (like me, thank
you very much! :-D), and to shake out any misconceptions and "dark corners".

Well, I have to vacate my "office" now as my daughter needs to go to bed,
I'll check in later on the laptop.
Cheers,
Ben

--
Regards,
Ben Ford
ben.for...@gmail.com
+447792598685


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Michael Sparks  
View profile  
 More options Oct 19 2008, 5:06 pm
From: Michael Sparks <spark...@gmail.com>
Date: Sun, 19 Oct 2008 22:06:53 +0100
Local: Sun, Oct 19 2008 5:06 pm
Subject: Re: [kamaelia-list] Re: Kamaelia AWS
On Friday 17 October 2008 18:47:05 Ben Ford wrote:

> Ah ha I see.

> I haven't come across the technique of using kwargs to override attributes
> set on the class before, it seems like a nice way to avoid needless
> subclassing and __init__ overriding. On the flip side,  I'd also say that
> it's got a lot of potential to trip you up, and would make the code harder
> to understand if you didn't write it yourself... That doesn't necessarily
> make it a bad idea, but I wouldn't have thought to do it that way, and
> likewise without the explanation I would have spent quite a while figuring
> out what was going on. This kind of thing may be part of the reason that
> experienced python developers find Kamaelia a little hard to get started
> on?

Well, it's a relatively new thing added to Kamaelia, so it's not widely used
as yet but it is incredibly handy. However I guess you're right an
experienced python developer might find it a little odd.

I've written up the rationale behind it here:
    * http://www.kamaelia.org/InheritableDefaultValues

> > if self.socketOptions is None:
> >    self.server = (self.TCPS)(listenport=self.port)

> I haven't seen this before either, why do you have the brackets around the
> TCPS class?

Well, that code could have been written like this:

      if self.socketOptions is None:
            TCPServer = self.TCPS
            self.server = TCPServer(listenport=self.port)

The reason for  brackets here:
    (self.TCPS)(listenport=self.port)

Is fundamentally due to a python syntax wart.

... because self.TCPS has effectively been defined like this:

   from Kamaelia.Internet.TCPServer import TCPServer
   ...
   self.TCPS = TCPServer

Meaning the type of TCPServer is a class.

However in python if you have this:
    self.TCPS(listenport=self.port)

Python sees that as .TCPS must be a method of self.

ie it's a little (unavoidable I think) wart of python.

I think if it'd looked like this ...
      if self.socketOptions is None:
            TCPServerFactoryCallback = self.TCPS
            self.server = TCPServerFactoryCallback(listenport=self.port)

... you probably wouldn't've batted an eyelid.

> These techniques are great, but they're also quite unusual... I'd comment
> that style/implementation decisions like this  in the Kamaelia codebase
> would be a great place for a tutorial, and an explanation of the rationale
> behind them.

Based on this, and that I'm mentioning this improvement in the new release
notes, I've written up the rationale behind this here:

   * http://www.kamaelia.org/InheritableDefaultValues

Any comments on that would be welcome.

> On the documentation side of things, what did you think of Sphinx?

It looks interesting, once the release is out the door, I really want to look
at what you've done.

> One of
> the other things that has added slightly to my overhead in groking Kamaelia
> is navigating the (online) documents and having the docs inline in the
> module docstring: Most of the time when I open a python source code file, I
> actually want to get straight to the code, and most python source I've does
> indeed have the source code right there at the top of the file.

This is stylistic I think. Personally I really like it when code has the
documentation inside the file with the code. Python's support for
docstrings really makes me prefer this approach by a long shot.

We do have a toolchain for extracting this documentation and putting it up on
the website here:

    http://www.kamaelia.org/Docs/Axon/Axon

and here:
    http://www.kamaelia.org/Components

> I really
> like that sphinx gives you such a comprehensive index and great navigation.

All that said, I haven't commented on sphinx yet simply because I haven't had
a chance to play with it, and do want to have a play to see what it can bring
us, since it looks like it could be useful.

> Based on our work with Kamaelia in building this AWS stuff, I have a couple
> of suggestions. These may or may not be good suggestions and I'm quite
> prepared to accept judgment either way. They might equally be purely
> personal idiosyncrasies ;-)

I think they may be, but ...

> I find the Kamaelia code structure to be a bit too "split up", I'd advocate
> not having one module for each class called the same thing, I much rather
> see:
> from kamelia.chassis import GraphLine, Pipeline, Carousel
> than:
> from Kamaelia.Chassis.Graphline import Graphline et al
> * (even if the above is achieved using a bunch of imports in __init__
> files)

... When we started down this, the concept of a chassis didn't even exist
originally so I'm slowly collating things together where they make sense. I'm
open to constructive suggestions like this about specific changes, simply
because I don't believe the "correct" structure for namespaces has been found
yet. Sometimes it's useful to have structure, and sometimes it's useful to
just turn around and go "it'd be handy to just be able to do" :

from Kamaelia import Pipeline, ConsoleEchoer, ServerCore, KitchenSink

Not quite sure how we balance those two yet, so I'm open to suggestion.

My timeline for fixing the overall namespace structure is before version 1.0
is released, which has a minimum timeline of 15 months. (since 0.7.X is due
next month, and 0.8.12 due in december, meaning we'll be synchronised into
Y.Y.MM versioning at that point).

> I'd like to see Sphinx used as a documentation tool, it ROCKS seriously!

As I say, I'll take a look when I get a tuit of the appropriate shape :)

> I think critiques like this are really valuable, both personally to new
> programmers who've just written their first Kamaelia stuff (like me, thank
> you very much! :-D), and to shake out any misconceptions and "dark
> corners".

Yes, I find it extremely useful. People can be very cautious about critcism,
whereas personally I find it very useful.

Now, back to writing the 0.6.0 release announcement :-)

Regards,

Michael.
--
http://www.kamaelia.org/Home


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2009 Google