2009/11/2 Michael Sparks <spark...@gmail.com> <snip> > Considering this thread actually started roundabout in April, 42 weeks > added onto that is Jan/Feb next year, so I wouldn't worry too much > about what 2 weeks is here :-) >
Not worrying too much, but good to be reassured anyway. :-) More seriously, we have just employed another programmer at my work, which more than doubles our programming resources, since I also do sysadmin type stuff in addition to programming. So I've started devoting some more time to the JsonRPC project. I'm aiming for approx day a week. It also helps keeps me sane - programming in Python still brings me a lot more joy than other languages. > > More seriously, I understand what it's like when work & personal life > go into overdrive & glad to hear that you're still planning on this - > as usual, if you need anything from me to help, let me know :-) > > Okay, I've got some questions. So far I've been using Kamaelia components to push data around, but still using 'ordinary' python classes to maintain overall system state. So in particular, most components in my system have a reference to a 'server' class instance, a 'manaager' class instance and quite a few to a 'connection' class instance. All of these are 'ordinary' python classes (not Kamaelia components), although they may have methods that create new Kamaelia components and wire them into the system. It seemed like a reasonable idea initially, but as I get further into my revised design, I'm finding that it seems to be increasing complexity rather than decreasing it. In particular, how a components works gets tied into these 'non-Kamaelia' classes and seems to break the 'plug and play' encapsulation that seems central to the idea of Kamaelia. I'm also concerned about thread safety since I'm running Kamaelia in the background (using Axon.background) but currently Kamaelia components can be created (and activated) in the foreground thread. I'm guessing that this might be not such a good thing. So, is there a better way? Mostly I need a way so that something in the foreground thread can say 'give me a list of all open connections' (or at least proxy objects for them) and 'send <data> to connection <foo>'. This is currently kept in a class that also acts as the protocol factory for ServerCore. Rather than ordinary python classes, should I have some components that keep the system state, and possibly use backplanes to query them? And I'm guessing it is best to keep all communication between the foreground thread and the Kamaelia thread via threadsafe queues? Any thoughts / feedback much appreciated. Cheers, Rasjid. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
