On Mar 20, 2009, at 10:59 AM, Noah Fontes wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1- Assemblage - Bundle - Cast - Group (too vague?) - Assembly - ClusterSome of these are okay, perhaps "assemblage" or something. See the bottom for a few other suggestions.
I sort of dislike assemblage because it feels too long. I dislike assembly because it's often used as the compiled executable. I dislike group because it's too vague.I dislike cluster as for me it implies a group of similar objects, not a group of related object (think cluster analysis, galaxy cluster, atomic cluster, cluster bomb)
David Zülke wrote:That's right. I kind of like "bundle", too.This has connotations other than representing a group of related components, namely that these components are intrinsically packaged together and somewhat separable from the framework as a whole. This is not the case.
I do agree with Noah on this.
[email protected] wrote:I'd say the action/view/model/template/cache/validation thingy is somesort of input->processing->output chain that uses the services of Agavi (the organizational unit in this case) like config, storage, routing, filter chain etc. to create output (web pages etc. with new links) that is used as feedback for new input.I think, in general, network architectures operate on a request ->processing -> response basis. Obviously this isn't always the case, butit's quite common.That said, I'm not sure we necessarily want to apply this concept here. While it's true that it operates this way, I don't think it should be adefining factor in how we represent the concept to the outside. I feel like it's more of a single entity that operates/processes itself; theexecution container is responsible for mediating input/output with thisprocessing mechanism.I think the earlier mentioned "processing unit" is not the worst suggestion. "Agavi Processing Unit" - APU (Nahasapeemapetilon!), "Processing chain" or similar perhaps? Even though it's not exactly a chain.I don't like "chain", "queue", "stack", etc. for reasons that Felixmentioned earlier. And, of course, "unit" causes problems with what Ericsaid above with regards to unit testing. I would also prefer to leavethe term "Agavi" out of this -- that way, the idea can easily be carriedover to other frameworks if they decide to implement a similar controller/execution container model to ours. I do like "processing" though as a potential alternative to "execution", even though I don't think it's necessary to have such an alternative, although I believe Felix dislikes this. With all that considered, we could do something like this (inspired by my comments about processing above): * Execution entity * Processing mechanism * Operational entity * Processing entity Or something like that, anyway.
I do like execution entity though it's not my favored.I dislike processing mechanism - it feels wrong. It also implies that the thing we're trying to name is actively doing the execution which is wrong.
I'm not really certain about the other two.
I also like the idea of an abbreviation, if we can't find anything else:* CEC: Contents of the Execution Container
Well in that case we really should aim for something cool like APU (though you're right, let's try to keep agavi out of it)
Abbreviations are quite difficult to make ambiguous, which is a nice advantage. Any thoughts on these? Noah
Here's another proposal submitted via ICQ: ----------------- Hi, how about: "The files that should not be named"? So we could call them Voldemort! OK I'm stopping that.All these files representing a function. Sometimes a very small and sometimes even more.
My suggestion is "Function Unit" or maybe "Function Package". /end of my 5 cent ----------------- Voldemort is a bad choice as there's already "Project Voldemort" ;)I sort of could get to terms with "Functional Package" or "Functional Unit". (FP and FU)
cheers felix
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
