- 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 prefixedwith 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 conflictwith "unit testing", as "unit" refers to a completely independent entityin that case, which is indeed misleading.- Assemblage - Bundle - Cast - Group (too vague?) - Assembly - ClusterSome 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 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 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
