Again me,

this is for ralph mainly, further ideas and questions:

1.) why not make the actions of providers use "return $output" to
proxy to the response object, instead of the lengthy
ZendL_Tool_Endpoint_Registry::getInstance()->reponse->append() function.

This is especially important if you think that a webservice might be
the Endpoint (relevant for Zend Studio or any other non-php
application which probably will communicate with Zend Tool via
SOAP/WSDL), where the returning of information out of service fascade
objects is the way Zend_Soap/Rest/XmlRpc/Json go, they could currently
not be used with the providers.

maybe also fetch all that is outputed to STDOUT within an provider
action and append it to response if in CLI Mode.

2.) The dispatching process seems a bit overhead, its current
functionality can easily be integrated back into class
"ZendL_Tool_Rpc_Endpoint_Abstract". Since all endpoints inhert from
the abstract they can additionally offer specialized "dispatching"
based on their requirements via abstract or overridable methods.

3.) Maybe i am just not finding the right point, but how are options
from the commandline like -m --major or somewhat parsed and returned
to the dispatched provider action? for example if i had a Provider
My_Provider_Form with a generate action. How would i signalize, that
"-m|--model", "-d|--doctrine" are allowed options for this one?

4.) How are project relevant provider (i.e. add controller/action)
linked from the commandline to a specific project?

In Django for example there is a global django tooling command
"django-admin" (like zf.sh and so on), whereas for each project there
is an additional "manage" script, that has a connection to the
projects definition files (zfproject.xml in our case).