Rasjid, I haven't read the rest of your thread, but I thought I'd comment on a couple points that you've made (and hope that I don't sound clueless).
> It also helps keeps me sane - programming in Python still brings me a lot > more joy than other languages. > Agreed. I've only programmed in a few languages as fun. Here's the motley mix of languages as fun as Python (IMHO)... 1. FORTH 2. LISP/Scheme etc 3. Interactive assembly language monitor (hehe) 4. D (the only edit/compile/run language in the list) 5. Lua (though I'm new to it) > 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. > Aha! Break the mold! :-) I'm playing with a bit of mold breaking myself. One of the results of the way I wrote my Axon implementation was that you can pipeline full objects as well as basic data types / strings etc. This is possible with Python, but I don't know if Axon/Python leverages it (probably -- it just falls out in the implementation). In any case, pipelining objects allows the receiving component to call the methods of the object received. For example, if you're pipelining Car objects (say econo car, sports car, luxury car) into an emmissions station component, you could call the "tune" method of the car coming through the inspection station and it would optimize according to the current emmissions standards. I guess this is a form of polymorphism and I don't know if it breaks the Axon encapsulation model or not. Polymorphic pipelining? Sounds like fun, but we'll see. > > 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. Yes. The flow-based programming model has a certain similarity to other programming languages that naturally support a "no-side-effects" policy. LISP/Scheme functional programming and FORTH's monad stack approach allow this type of natural encapsulation and each succeed to various degrees. > 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. I think I understand your issue here (possibly). I've been implementing Axon in D (or a reasonable facsimile) and this issue has come up several times. Essentially I want to make it possible to click on a component output and have the system query all conformable component inputs. There's a number of different names for this, but the usual one is a "service" model where the user (or mainline program) can ask the kernel (bus whatever) "give me a list of all conforming inputs to this output". In a strongly typed language like D this is pretty important. Luckily D has features that allow this type of introspection. I can even model the introspection using filtered enumerators. > 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? > > I'm currently refactoring my Axon/D class model so that much of this state information is contained in a kernel or bus class. This class acts as a factory for mailboxes and while components can communicate directly via the mailboxes, there's no complex handle cross-coupling between the component, its outboxes and the destination inboxes. When a mailbox is destroyed it is done by the kernel for proper cleanup. This single refactor eliminated a lot of awkward cross-coupling. It stems from single responsibility. One class is responsible for process creation and relations (maybe that's too much). I believe the proper implementation of this idea is an extension of the Observer pattern -- an extension that eliminates cross-coupling between the observed and the observer. An extension of the basic Observer is "Listener" and a superset of Listener is the Service or Whiteboard pattern. The Whiteboard completely de-couples the observer and observed and only creates a minimal amount of tracking overhead. > Any thoughts / feedback much appreciated. > > For what it's worth. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
