Call it a body. - Eric
On Fri, Mar 20, 2009 at 11:51 AM, David Zülke <[email protected]>wrote: > What about "squad"? It would describe the sense in a relatively good > fashion (a bunch of subjects with specialized tasks/abilities forming a > small operational unit), and it has the advantage that it's short and > memorable while at the same time impossible to confuse with any other part > in the framework as it does not describe a technical thing. > > - David > > P.S: if one were to be anally pedantic about details, it would have to be > "fireteam", which is the smallest military unit of organization, but that > would be a bit much, and, again, confusing. The word "squad" doesn't have > this immediate in-your-face association with military topics (police, > firefighters, German THW have them too). > > > > On 20.03.2009, at 11:59, Noah Fontes wrote: > > -----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 >> >> > > _______________________________________________ > users mailing list > [email protected] > http://lists.agavi.org/mailman/listinfo/users > >
_______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
