Re: [kamaelia-list] Threaded component message handling

[Sylvain Hellegouarch]

Hi,


On 16 October 2013 16:22, Michael  wrote:

> Hi,
>
> gevent would be nice, on the (obvious) proviso any implementation
> integrated approrpriately with other parts of the gevent ecosystem.
>
> Michael
>
>
Gevent is rather too intrusive for my liking unfortunately and a gevent
based Axon would have these implementation details on the outside world I'm
afraid :/

-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

-- 
You received this message because you are subscribed to the Google Groups 
"kamaelia" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kamaelia+unsubscr...@googlegroups.com.
To post to this group, send email to kamaelia@googlegroups.com.
Visit this group at http://groups.google.com/group/kamaelia.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [kamaelia-list] Threaded component message handling

[Sylvain Hellegouarch]

Hi guys,




On 16 October 2013 16:12, Michael  wrote:

> Found the code I was referring to - it's here:
>
> http://code.google.com/p/kamaelian/source/browse/Sketches/Axon/Axon2/
>
> Never really reached the stage of usefulness for reasons irrelevant to the
> code previously discussed on list.
>
>
> Michael.
>
>
>
> On 16 October 2013 15:06, Michael  wrote:
>
>> Hi Jim,
>>
>>
>> I'm not too surprised to hear about the increase - it's probably akin to
>> the boost we got when we optimised out the Postman class. In the past I've
>> written scratch versions of Axon using threads as the default and
>> Queue.Queues as the default with direct linkage and that all worked fine.
>> Likewise I also did a version using multiprocessing library to default to
>> processes and channels and that had some interesting results.
>>
>> Neither of these ever got merged onto the main codebase because I didn't
>> have a need at the time - and the performance I saw was sufficiently good
>> for the tasks in hand.
>>
>>
>> Michael.
>>
>>
>> On 16 October 2013 13:53, Jim Easterbrook wrote:
>>
>>> I've been experimenting with Axon's threaded components. Currently
>>> incoming messages are delivered to the wrapper, which forwards them to the
>>> thread at its next scheduler slot. I've written a "threadedsink" class to
>>> replace the "realsink" class used when creating an inbox. It's based on
>>> Queue.Queue - the append method puts a message on the queue and wakes up
>>> the thread directly, without the wrapper component getting involved.
>>>
>>> Similarly, the threaded component's "send" method can check to see if
>>> the receiving inbox's sink is a "threadedsink" object, and if so append the
>>> outgoing message directly. Otherwise the usual threaded component out queue
>>> is used.
>>>
>>> These two changes give me much better performance with pipelines of
>>> threaded components. Messages flow from one component to the next without
>>> the scheduler having to do anything.
>>>
>>> Note that I haven't given much thought to what happens if links are made
>>> or unmade while messages are flowing. That's something I try and avoid
>>> doing. (Turn the water off before disconnecting the hose.)
>>> --
>>> Jim Easterbrook
>>> Senior Research Engineer
>>>
>>> BBC Research & Development South Lab
>>> BBC Centre House
>>> 56 Wood Lane
>>> London W12 7SB
>>>
>>> Phone:  +44 303 040 9705
>>> Mobile: +44 7590 307002
>>> FAX:+44 20 8811 8815
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "kamaelia" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to 
>>> kamaelia+unsubscribe@**googlegroups.com
>>> .
>>> To post to this group, send email to kamaelia@googlegroups.com.
>>> Visit this group at 
>>> http://groups.google.com/**group/kamaelia
>>> .
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out
>>> .
>>>
>>
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "kamaelia" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kamaelia+unsubscr...@googlegroups.com.
> To post to this group, send email to kamaelia@googlegroups.com.
> Visit this group at http://groups.google.com/group/kamaelia.
> For more options, visit https://groups.google.com/groups/opt_out.
>


Any thoughts on using gevent in that context? I'm not a massive user of
greenlets but having used erlang quite a bit, I see their appeal.

-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

-- 
You received this message because you are subscribed to the Google Groups 
"kamaelia" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kamaelia+unsubscr...@googlegroups.com.
To post to this group, send email to kamaelia@googlegroups.com.
Visit this group at http://groups.google.com/group/kamaelia.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [kamaelia-list] Re: Is Kamaelia still alive?

[Sylvain Hellegouarch]

Hi guys,


On 30 September 2013 03:10, Michael  wrote:

> Hi Jim,
>
>
>
> On Sunday, 29 September 2013 23:05:21 UTC+1, jim...@gmail.com wrote:
>>
>> Just finished reading Morrison's "Flow Based Programming" 2nd addition,
>> and this sounded like one of the further along Python oriented tools.
>> Complete lack of traffic here in 2013 doesn't seem too encouraging
>>
>
> Alive or dead ? Whether a project is alive or dead depends entirely on
> userbase. Kamaelia reached maturity and was used internally at my workplace
> (BBC) for a number of projects, and there is at least one project that
> still uses Kamaelia internally. Outside the BBC, one major barrier to
> adoption was syntax. While I don't think many people disagreed with the
> power of pipelining, and composition of component systems, the process of
> building components led to code that some people liked, and other
> vehemently disliked.
>
> Internally I was asked by a senior colleague (a couple of years ago) to
> stop working on the project publicly, and to cease using it in new projects
> because it was difficult for them for reasons never disclosed to me. Since
> I respected that individual, was changing projects anyway, I decided to
> agree to this. Anyone internally who reads this is unlikely to be able to
> guess the individual correctly either, so please don't, he says knowing
> there's a peanut gallery :-) As a practical effect though, this means I no
> longer develop at work using kamaelia, and outside work I don't really have
> the time.
>
> The killer for me though in agreeing was in discovering that community
> feedback I'd had was actually misleading. We had one large piece of code
> effectively donated to the project in enthusiastic tones, which was really
> welcome but oddly never heard from the contributor again. However, some
> time later I discovered this comment on stackoverflow from the author:
>
>
> I used kamaelia for an app - it was extremely painful. IMHO there are
> other, better options for concurrenct in python (most of which are
> mentioned above)
>
>
> Now, given one of the whole points of Kamaelia was to make concurrency
> easy to work with and not painful, the above comment made me realise why
> I'd give talks & tutorials about Kamaelia and receive nice comments on one
> hand, but never see any take up - people were just too damn polite! While I
> was using Kamaelia for my projects I was willing to continue work on it,
> but since that has essentially ceased (for reasons hinted at above), it is
> for all intents and purposes a "finished" project.
>


Though I don't mind much about the internal politics at the BBC, I must
admit I'm glad I can closure on this one. I used to be hang around the IRC
channel and was always happy to discuss everything about Kamaelia but as
everyone suddenlmy disappeared it felt odd. Perhaps I simply missed the
memo back then that the project was driverless and if that's the case, my
mistake. It nonetheless felt like I had spent quite some time around that
project (even though I didn't do much on the project itself) and that no
one had even tried to notify anyone that the project was not worked on
anymore. It was disapointing I must say.



>
> I am likely (very likely) to revisit this space at some point since I know
> the model for development works, and is reliable and I rely on the code
> every day, and it does run bug free, but when I do, I'm likely to start
> from the perspective of syntactic sugar early on. At the moment, the day
> job is 99% C++ (yeah, I know), so it will be a while.
>
> For now, though, if your question means "will there be continuing
> development on kamaelia?" which is what people normally say when they ask
> "Is X dead", I would say no - unless someone else takes up the project that
> seems unlikely. If there's serious bug fixes that someone needs
> incorporated, then the github repository will obviously be updated to
> reflect this but otherwise, no.
>
> The ideas though, those I do reuse, and when forced into a corner where
> I've got very little time to build something i need to be able to rely on
> absolutely, *then *I pick up Kamaelia. A shame really - especially
> considering I still entrust Kamaelia day to day with systems and data
> important to me.
>
> In the long term the general model of communicating things which don't
> share state communicating point to point over message queues, and via
> shared public and private pub/sub backplanes, transferring stateless
> messages is one that isn't going away, and being incorporated into more
> system models, and languages with every passing year. However, syntax
> matters - bear that in mind when choosing a library. If you haven't chosen
> a language yet, I'd seriously recommend either Scala or Go - primarily
> because they've both had this sort of coding model built in from the ground
> up.
>


Both great choices indeed. I would also add erlang which I've always loved
when it comes to concurrency.

-- 
- Sylva

Re: [kamaelia-list] Kamaelia's Future

[Sylvain Hellegouarch]

Hi,



>
> I'm not disappearing, but I think for things to move on, the project
> needs to explicitly say "this code is now end of line and something new
> will replace it, but don't worry, it *is* maintained, looked after and
> used".
>
>
I think that's the key rationale. A project that doesn't state well it's
not actively being developed any more looks worse because people feel it's
being unloved and are scared of using it. I therefore agree that the
project should enter a phase that acknowledges its end of line status.

Cheeseshop provides two useful classifiers for it:

Development Status :: 6 - Mature
Development Status :: 7 - Inactive


On a personnal note I'm happy that there's life around here because, even
the IRC channel seemed rather dead now.

I think a move to github is not really necessary if you're not planning on
developping the project any further, however, github does offer some
visibility to a project and pull requests may make it easier to merge
fixes. Considering github seems to be supporting svn now, it may be quite
simple to migrate as well.
-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

-- 
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.

Re: [kamaelia-list] Nifty uses and features.

[Sylvain Hellegouarch]

On Wed, Aug 11, 2010 at 12:16 PM, Matt Hammond wrote:

> The attraction to me if the simplicity of use and the lower overheads
>>> compared to using a threaded component to send timing signalling.
>>>
>>
>  With the understanding of blocking the whole Python process (hence the
>> scheduler) by not using a thread for the timer.
>>
>
> It doesn't block the scheduler. It uses the python Timer class, which uses
> a thread. When the timer times-out, the component is re-awoken, if paused.
>
>
>
Damn, that'll teach in reading the code more properly. I assumed it was a
time.sleep(...). Sorry for that.



-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

-- 
You received this message because you are subscribed to the Google Groups 
"kamaelia" group.
To post to this group, send email to kamae...@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.

Re: [kamaelia-list] Nifty uses and features.

[Sylvain Hellegouarch]

On Wed, Aug 11, 2010 at 11:55 AM, Matt Hammond wrote:

> On Wed, 11 Aug 2010 10:18:50 +0100, Sylvain Hellegouarch 
> wrote:
>
>  I'm usually not a massive fans of mixins as I find they recreate what is
>> the
>> core nature of Axon: composability. If I was using my threaded monitor
>> above, I'd have something like:
>>
>> Pipeline(ThreadedMonitor(),
>> TestComponent(),PassItOn(),ConsoleEchoer()).run()
>>
>>
>> Where TestComponent wouldn't be a mixing anymore. To me this avoids hiding
>> the fact the TestComponent is a timer. Instead it states that it requires
>> a
>> timer which is a different view.
>>
>
> Its a mix-in because I was lazy and didn't want to branch Axon and modify
> the Component class directly :-)
>


I cant applaud the lazyness-creativity.



>
> The attraction to me if the simplicity of use and the lower overheads
> compared to using a threaded component to send timing signalling.
>


With the understanding of blocking the whole Python process (hence the
scheduler) by not using a thread for the timer.


-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

-- 
You received this message because you are subscribed to the Google Groups 
"kamaelia" group.
To post to this group, send email to kamae...@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.

Re: [kamaelia-list] Nifty uses and features.

[Sylvain Hellegouarch]

On Wed, Aug 11, 2010 at 1:06 AM, Matt Hammond  wrote:

> >> An unrelated question: What is the best way to set a timer inside of a
> >> component? I am using the threaded Timer, but it is problematic inside
> >> of
> >> the component, it only fires once and cannot be restarted without error.
> >> It
> >> looks like it's underlying thread handling is botching up the top level
> >> thread processing.
>
> > You might want to look at an old code of mine which allowed to reset a
> > timer:
> >
> >
> http://trac.defuze.org/browser/tags/headstock-0.3.3/headstock/lib/monitor.py
> >
> > Still a threaded component mind you.
>
> Gloria, Sylvain: you both got me thinking. Have just committed a little
> experiment:
>
>
> http://code.google.com/p/kamaelia/source/browse/trunk/Sketches/MH/TimerMixIn.py
>
> Would be interested to hear what you think. Feel free to try it out. The
> bottom half of the file is an example usage.
>
>
>
>
I'm usually not a massive fans of mixins as I find they recreate what is the
core nature of Axon: composability. If I was using my threaded monitor
above, I'd have something like:

Pipeline(ThreadedMonitor(), TestComponent(),PassItOn(),ConsoleEchoer()).run()


Where TestComponent wouldn't be a mixing anymore. To me this avoids hiding
the fact the TestComponent is a timer. Instead it states that it requires a
timer which is a different view.


-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

-- 
You received this message because you are subscribed to the Google Groups 
"kamaelia" group.
To post to this group, send email to kamae...@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.

Re: [kamaelia-list] Nifty uses and features.

[Sylvain Hellegouarch]

>
> Matt, thank you, this is really great! I will respond in more detail once I
> test this out. I am certain you've saved me huge amounts of time.
>
> An unrelated question: What is the best way to set a timer inside of a
> component? I am using the threaded Timer, but it is problematic inside of
> the component, it only fires once and cannot be restarted without error. It
> looks like it's underlying thread handling is botching up the top level
> thread processing.
>
> Thank you!
> Gloria
>
>
>
You might want to look at an old code of mine which allowed to reset a
timer:

http://trac.defuze.org/browser/tags/headstock-0.3.3/headstock/lib/monitor.py

Still a threaded component mind you.

-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

-- 
You received this message because you are subscribed to the Google Groups 
"kamaelia" group.
To post to this group, send email to kamae...@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.

Re: [kamaelia-list] Dynamic Graphline components?

[Sylvain Hellegouarch]

On Mon, Aug 9, 2010 at 9:35 AM, Matt Hammond wrote:

> On Mon, 09 Aug 2010 08:24:37 +0100, Matt Hammond <
> matt.hamm...@rd.bbc.co.uk> wrote:
>
>  *Michael: the relevant cookbook page appears to be borked atm:
>> http://www.kamaelia.org/Cookbook.html
>>
>
> Oops - that should be:
>
> http://www.kamaelia.org/Cookbook.html.html/Carousels.html
>
>
I agree with Matt that you should look at the Carousel component to get
inspired from it (or use it directly if it's just what you need). Graphlines
are rather static components, once they are started there's no real API to
actually change them at all and you'd have to recreate them entirely which
isn't really suitable most of the time.

-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

-- 
You received this message because you are subscribed to the Google Groups 
"kamaelia" group.
To post to this group, send email to kamae...@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.

Re: [kamaelia-list] Re: Announcement : Kamaelia License Change : Apache 2

[Sylvain Hellegouarch]

>
> To cut a long story short, the machine the site was hosted on was
> being shut down, moved and should've been switched back on - meaning
> the current host was intended to be temporary. Since the original host
> was never switched back on it's left the site in limbo.
>
> Deciding to bless the new host as permanent brings some opportunities,
> which I'll come back to another night. However, any comments and
> suggestions would be welcome in the meantime would be welcome.
>
>
>
Probably not a surprise but I would definitely suggest WebFaction. They've
always been responsive and reliable.

http://www.webfaction.com/

-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

-- 
You received this message because you are subscribed to the Google Groups 
"kamaelia" group.
To post to this group, send email to kamae...@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.

Re: [kamaelia-list] Announcement : Kamaelia License Change : Apache 2

[Sylvain Hellegouarch]

>
> Anyway, I'm delighted to be able to make this announcement. I'm making
> changes to the repository now to reflect this.
>

I can only concur with others that it's a great move for Kamaelia. Well done
as I know that you had to fight for it.

- Sylvain
-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

-- 
You received this message because you are subscribed to the Google Groups 
"kamaelia" group.
To post to this group, send email to kamae...@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.

[kamaelia-list] Re: Autoloading Components based on Imports

[Sylvain Hellegouarch]

Matt Hammond a écrit :
>> So some questions arise:
>>1. Good idea or not?
>>2. Really? Could be viewed as bad mojo & messing about one step too
>> far.
>>3. If OK, should it be static? ie the list of what gets imported and
>>handles what dealt with by a table lookup in Kamaelia/__init__.py ?
>>4. Or should it go "OK, I was imported here, I'll rummage around in all
>> my
>>subdirectories, in this overall order"
>>5.  Do 3, then 4, if the name wasn't found in 3.
>>6. The other way round ?
>>7. Do we allow extra search paths for the case of 4 ?  (think sys.path
>> for
>>modules)
>>8. How about allowing extra lookup tables to be added in the case of 3?
>>9. lots more possibilities.
>> 
>
> I can see it would be much less verbose and that is a *good* thing! If
> nothing else, from writing examples in documentation, where brevity is
> highly desireable, adding all those import statements can be tedious and
> ugly.
>   
True and yet I welcome that verbosity. I did a bit of Ruby and the first 
thing that annoyed me was that there was lots of magic going on in 
module finding and since the language allows you to change things rather 
dramatically at so many levels I ended up being lost and frustrated quickly.

I appreciate the fact that the current verbosity means I know where 
things are coming from and never worry about name clashing.

- Sylvain

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[kamaelia-list] Re: Branch Status

[Sylvain Hellegouarch]

> Also, there seems to be sufficient interest to warrant an Actor subclass of 
> Microprocess (ie a microprocess only with an inbox and event dispatcher 
> rather than inboxes and outboxes), so adding that seems reasonable, but 
> requires thought. (It's trivial to do using Axon, but bears examination)
>   
At a quick glance I like the idea and would probably use it (in fact 
part of headstock is more or less doing something like that).

- Sylvain

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[kamaelia-list] Re: Load

[Sylvain Hellegouarch]

Lauri Pesonen a écrit :
> Hi,
>
> I'm seeing idle Kamaelia apps running at 2.5% CPU constantly on a
> 2.4GHz Core 2 Duo. Is this just the way the framework works or could
> it be possible to lower that number. I'm hoping to implement a deamon
> app for desktop machines so I would like to see a load of 0% for an
> idle app :-)
>
>   
It's not normal indeed. Most likely, one of your component doesn't pause 
when it's not needed making the scheduler runs like crazy. Ensure you 
have somthing similar to:

if not self.anyReady():
   self.pause()
 
yield 1

In every components.

- Sylvain

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[kamaelia-list] Re: GSOC 2008 branches/private.*gsoc2008 *all* unmergeable

[Sylvain Hellegouarch]

Michael,

Rather than replying to your various points here I'll make a more global 
response

I've considered this problem since you've raised it the other day and I 
think it's a two fold one (as most of the time).

Yes, it's slightly disapointing seeing people leaving the boat once GSoC 
was over but the good news is that this year most of the students have 
sticked to IRC or the list. I'm fairly sure that those who haven't 
actually have very good reasons not to show up any longer.

However I believe you might be expecting too much here. The purpose of 
GSoC, prior to anything else, is to introduce some young motivated 
people what FOSS is all about and how a project may actually be handled 
(I know you know that ;)).

 From that regard, I believe this is a success. Our students have shown 
interests and grown through their time with us.

That being said, I would dare say that we shouldn't expect more from 
them. Of course we both wish for them to stick around *and* be active to 
the project but that doesn't mean they owe the project anything in any 
shape or form.

You know as well as I do that FOSS is a commitment in time but to find 
the energy to do it you must have more than fun. Fun is good to start an 
idea, not to commit to it on a longer run.

Applications this year were about having fun, like any demo, once they 
were done, they were over. Moreover let's face it, none of those 
applications were useful in their state. It's not a shame to drop 
projects when you consider the energy and time you put into them are 
over a certain treshold.

Our students are rather young and new to FOSS for most of them, they 
don't yet have an idea of where their interests may fall into. When I 
started 10 years ago I toyed with SDL to write a game until I realised 
this wasn't my field of interest (which is networking ;)) and I dropped 
SDL overnight.

One lead we could decide to follow in that respect is to keep the same 
students next year but with projects more involving and more geared 
towards useful/reusable to everyone.

I hope you didn't take this reply the wrong way, I really car about 
Kamaelia and I've noticed  you were feeling a bit alone in this at 
times. I only chime in where it seems appropriate but I care for the 
project overall :)

- Sylvain





--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[kamaelia-list] Re: Running Kamaelia in the non-main thread

[Sylvain Hellegouarch]

Rasjid a écrit :
> Posted a longer message to the list yesterday, but its seems to have
> been lost.  Just wanting to confirm that Kamaelia works well even when
> not running in the main thread.  I think what I want is LikeFile
> (http://www.kamaelia.org/Cookbook/LikeFile).  One of my interests in
> writing custom protocols that need to be embedded in other frameworks,
> such as Windows COM or under Mozilla's XPCOM, or just with a GUI
> toolkit like wxWidgets.  I have worked a bit with Twisted, but got
> discouraged when it appeared that Twisted *really* wanted to be
> running in the main thread.  (This was over a year ago so perhaps
> things have changed - but I still think that Kamaelia will fit my
> brain better.)
>   


Just to confirm that Kamaelia has no trouble at all running in a thread 
different from the main one.

- Sylvain

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[kamaelia-list] Re: repost: Simple Chat Server Example

[Sylvain Hellegouarch]

> One thing that I personally would like to see though are some examples
> of how to use some of the more low level Kamaelia things like the
> selector and the CSA.

You can dig into my various code :)

- Sylvain

-- 
Sylvain Hellegouarch
http://www.defuze.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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/kamaelia?hl=en
-~--~~~~--~~--~--~---

[kamaelia-list] Re: P2P Swarming Radio System

[Sylvain Hellegouarch]

Hi Manuel,

Welcome to the wonderful world of Axon and Kamaelia that'll open up your
eyes and potentially even bake cookies for you.

Always nice to see more new people around here.

- Sylvain

>
> Hello.
>
> I'm new in the list. Let me introduce my self. I'm Manuel Cerón,
> student of Software Engineer at the University of Cauca, Colombia. I
> was participating in the last Google Summer of Code for The Mono
> Project. I was looking for ideas for my thesis / graduation project,
> and I thought that there was really good ones in the lists of the
> Summer of Code Mentoring organizations. In the search, I found the
> Kamaelia project and I was attracted by the Swarming P2P Radio System
> idea. I've been talking with my supervising professor, and he likes
> the idea too. I'm going to work on this.
>
> I've been collecting information about P2P, Swarming, and streaming.
> Besides others, I've read the Yatin Chawathe's paper on the
> ScatterCast Broadcast System [1] as suggested in the ideas page and
> some papers on Mesh-based P2P Streaming by Nazanin Magharei and Reza
> Rejaie [2]. If you know about any other relevant paper o book which
> can be useful to me, please let me know.
>
> Of course, I want to use Kamaelia for the implementation, so it's
> probable that you're going to have me around asking questions.
>
> That's all for now. Greetings.
>
> Manuel.
>
> [1] http://research.chawathe.com/people/yatin/publications/
> [2] http://ix.cs.uoregon.edu/~reza/
>
> >
>


-- 
Sylvain Hellegouarch
http://www.defuze.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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/kamaelia?hl=en
-~--~~~~--~~--~--~---

[kamaelia-list] Re: Kamaelia AWS

[Sylvain Hellegouarch]

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

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/kamaelia?hl=en
-~--~~~~--~~--~--~---

[kamaelia-list] Re: Kamaelia AWS

[Sylvain Hellegouarch]

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

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/kamaelia?hl=en
-~--~~~~--~~--~--~---

[kamaelia-list] Re: Your Aha! moment?

[Sylvain Hellegouarch]

>
> Hi,
>
>
> This is borne from a discussion on IRC, and I figure it'd be useful to
> ask here.
>
> What was your "aha!" moment with Kamaelia?
>
> For example, I've had concurrency researchers ask me "So what you're
> doing is just  melded with  and ", what's new? And given the
> response "We're trying to make it usable". At which point their face
> changes and they go "oh", and the context suddenly makes sense
> - like the final piece of the puzzle.
>
> Despite a fair amount of working with kamaelia being "plain old
> writing normal looking python code", and fair amount of it revolves
> around working with and joining together components to bootstrap
> things (eg using pipelines, subcomponents etc).
>
> Personally, I'm too close to this question to answer it, but what was
> your "aha!" moment where it all fell together (if it did :-), or did
> it just seem like common sense, or ... ?
>
> Fundamentally, that's really the key thing I need to communicate this
> weekend, and so any suggestions (on or off list) would be very
> interesting to hear.
>
> The reason I'm asking is because it's been brought to my attention
> (indirectly) that the issue that what I'm really talking about when
> I'm talking about creating and using components is in fact system
> decomposition and design - something which can be less obvious to some
> than others.
>
> As a result, any "aha!" moments about how you realised "ahhh, that's
> how you build things with this", would be really useful.
>

I think I've had many minor "aha!" moments with Kamaelia or I should
rephrase I've had consistent "aha!" moments throughout my learning of it.
Probably my most favourite time was when I understood the absolute power
of the Graphline component.

That component is terrific because it is so hierarchic and associating
that with the explicit nature of describing linkages means you can have a
quick overview of how your application is structured. That suits XMPP very
well considering XMPP is a stream of namespaced XML messages and that XML
is rather hierarchic in nature.

One aspect I've truly come to appreciate from Axon is a real separation of
concerns between the function and how it relates to the rest of the
program [1]. Let me illustrate what I mean.

For instance, let's say I would have written my XMPP implementation with a
more traditional object oriented architecture, I would probably have had
to create a XMPP stanza dispatcher based on the namespace of the stanza.
Then objects would have had to register callbacks to the dispatcher for
each combination of namespace and other parameters. In fact that's how the
initial draft of headstock was designed [2].

The issue I have with this pattern is that it might not integrate well
with another application that is designed differently or the blend may be
less than readable.

Whereas with Axon and Kamaelia, you do not need to write said dispatcher,
it comes for free. You don't have to worry about integration with other
Kamaelia based applications since they'll follow the same pattern. In
other words, developers can focus on learning what your program does, not
how to reuse it in their own code.

Well there is still a learning curve. Jason knows too well that
understanding headstock [2] is not a piece of cake, but once he was at
ease with how Axon worked he felt much more confident about how to reuse
headstock.

In that regards, one of the best decision the project has made was to
separate Axon from Kamaelia. In fact the scope covered by Kamaelia is a
true testimony of the power that lies in Axon's design.

- Sylvain

[1] http://en.wikipedia.org/wiki/Computer_program
[2] http://trac.defuze.org/browser/tags/headstock-0.1.0
[3] http://trac.defuze.org/wiki/headstock

-- 
Sylvain Hellegouarch
http://www.defuze.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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/kamaelia?hl=en
-~--~~~~--~~--~--~---