-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Brisco wrote: > So, if I gather correctly, David does not like the name being prefixed > with execution due to conflict with other terms. Why prefix the term > with execution at all? Just calling it a unit conflicts with unit > testing. However, what about some synonyms?
Because it has to do explicitly with the execution of several elements of the framework. That said, I didn't consider the potential conflict with "unit testing", as "unit" refers to a completely independent entity in that case, which is indeed misleading. > - Assemblage > - Bundle > - Cast > - Group (too vague?) > - Assembly > - Cluster Some of these are okay, perhaps "assemblage" or something. See the bottom for a few other suggestions. 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. [email protected] wrote: > I'd say the action/view/model/template/cache/validation thingy is some > sort 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, but it'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 a defining factor in how we represent the concept to the outside. I feel like it's more of a single entity that operates/processes itself; the execution container is responsible for mediating input/output with this processing 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 Felix mentioned earlier. And, of course, "unit" causes problems with what Eric said above with regards to unit testing. I would also prefer to leave the term "Agavi" out of this -- that way, the idea can easily be carried over 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 also like the idea of an abbreviation, if we can't find anything else: * CEC: Contents of the Execution Container Abbreviations are quite difficult to make ambiguous, which is a nice advantage. Any thoughts on these? Noah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknDaRsACgkQhitK+HuUQJTLmwCfemBSLq6rYuYBb15VzyYtvoTA Wn4AoJVpu3TwsQmgicrb+85H9dtpefzV =iPS3 -----END PGP SIGNATURE----- _______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
