On Mon, Jul 27, 2009 at 4:48 AM, Michael Sparks <[email protected]> wrote:
> Hi Nathan, > > > I'm going to chop this into 2 threads if that's OK, to make it more > manageable. I'll chop the outbox -> inboxes & mascot stuff into here to > leave > the syntactic suggestions in a separate thread, so that they're easier to > follow. > Good idea. [snip] > Incidentally, the reason for one outbox -> one inbox rule in kamaelia is > based > around making the system more deterministic. > Could you be a little more specific here? How do multiple sinks make things less deterministic? Is it because you don't know which sink component will run first? > Backplanes are useful for this sort of thing, but aren't the only mechanism > for handling this. Also I don't think current code is the final example of > this sort of thing either! > > Current options for one outbox -> multiple inboxes are found here (in rough > order that they were written) : > > 1 Kamaelia.Util.Fanout : Fanout > 2 Kamaelia.Util.Splitter : Splitter > 3 Kamaelia.Util.Splitter : PlugSplitter & Plug > 4 Backplane > My apologies if this is already documented somewhere, but do you think you could write up a brief description of the relative advantages of each of these, and what problem they were designed to handle (or handle better) over their predecessor(s)? Of course, a link will do if it's already out there. > More recently though, when writing the PAR component, I realised that a > generic Chassis component for handling splitting would be much nicer, but > with a PAR component it's very unclear what the policy should be. Is it > demuxing? Is it load balancing? Is it splitting ? etc. > May I make a suggestion? I don't find PAR to be a very descriptive name. It looks like an acronym for something. I recommend renaming this component to something like Parallel. > > Since I couldn't decide, I decided to leave that unsaid for that point in > time: > * http://tinyurl.com/nbespx > > And left this note in it's docs: (with a couple of corrections) > > PAR(inputpolicy=None, outputpolicy=None, *components) > > Inputs to inboxes can be controlled by passing in a policy. The > default > policy is this:: > > messages to "control" are forwarded to all children > if a control message is a shutdownMicroprocess, shutdown > when all children exit, exit. > messages to "inbox" are currently ignored > > See the module docs on writing a policy function. > > Policies > > To be written. The idea behind policies is to allow someone to override > the > default behaviour regarding inbox data. This potentially enables the > creation of things like threadpools, splitters, and general workers. > > The advantage this would have is then you could do this: > > Pipeline( > FrameSource(), > FrameTagger(), > SplitterChassis( > EdgeDetect(), > MotionDetect(), > ImageAnalyser(), # I dunno, I'm not an image person :-) > ), > Combiner(), # could take tags and use them for combining > ... > ) > Where a splitter chassis is just a specialisation of PAR - with a policy > that > says "copy to all children". Having a splitter chassis like this would > simplify a lot of cases IMO. > Ok, so SplitterChassis would send all messages in its inbox to all the inboxes of its children components, right? The thing I'm missing here is what the outputs are, and how it is wired up with Combiner. > FWIW, as noted I'm seriously thinking about dropping support prior to > 2.5.1, > with the intent of using that to improve things. I also wasn't saying that > your syntax ideas weren't implementable in other languages etc, just > more where I'm coming from :-) I can get quite inventive with some > things, but just want to make sure I'm not making it /painful/ to switch > if necessary. :-) > Right. I was just thinking that in case you don't drop 2.2 support for some reason (and until you do) it would be best to think about some of the consequences of that now, rather than later. > > I certainly agree for example that Graphlines can get messy, but it's kinda > tricky to see how to express them better in python without resorting to > code > that looks like ascii art. Your suggestions as a result look like an > interesting compromise :-) > Yeah, graphs/networks are really best represented graphically in almost all cases. > > > By "can't read how it maps across", do you mean you are having difficulty > > understanding the intent of the code, > > That. I'm not saying that I can't read it, but I can't read it with > certainty > that I'm reading it the "right" way. This is probably a factor of how I > think > rather than the code. I doubt you're the only person it's clear to ! :-) > When I post my code, I'll also post a version of the example updated to work with it. That way, you can play around with it and see how it works. > > > I may also get in contact with Richard Taylor incidentally who has been > > looking into a (very old) system called MASCOT for a while, where > channels > > and pools - which have remarkable similarities to inboxes & the > > tracker/STM, for a summary of those. > > > > The reason behind that is because a) MASCOT worked b) it's been largely > > forgotten, but is hugely relevant c) if we start making boxes attributes > or > ... > > Is there a website for this? Is it open source? > > It's ancient (in computing terms - nearing 40 years old...) and became an > open > standard (or nearly did - through the BSI maybe). So old it went through a > traditional/formal standardisation process *years* before the development > of > the web. > > The downside is there's very few websites on it. Search term: > * Modular Approach to Software Construction Operation and Test > > Wikipedia page: > > http://en.wikipedia.org/wiki/Modular_Approach_to_Software_Construction_Operation_and_Test > Thanks. I'm still going over these pages. From the looks of things, MASCOT is a methodology and not a particular piece of software. Methodologies tend to have longer life-spans than software, and even languages to a lesser degree, but 40 years is still pretty old. > > This page has a link to "MASCOT 2002": http://www.object-forge.com/ > but has a wierd page setup preventing linkage directly to the content. > I see what you mean. That's a good example of someone going nuts with Javascript! Take care, Nathan Davis --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
