Thanks Petr for your review
0/ "The standard external page approach problem is that it would not list all available functions for particular user, but instead would only list all external functions."
>> I think it's a issue as we don't want to let some developers know what external functions are activated. So they don't complain that other entities have access to these functions.
"1/ the docs page can not be disabled - custom login mechanism breaks $CFG->forcelogin (security)"
>> it seems to me less important than 0/. Can you explain why it breaks and why it implies? The login page doesn't log into Moodle, just authenticate web service user (as the web services do)
"2/ can not be integrated with the admin settings tree because it does not use standard sessions"
>> I still think it is not a good idea to display any admin tree neither any links, or Moodle menus to an external developers.
"3/ IP restrictions cause problems - browser does not have the same IP as the ext. system"
>> right, I put it for protection thinking we could remove it easily. I'll remove it.
"4/ protocol checks missing (security)"
>>good catch too, I missed out this point
"5/ token auth missing - it might be very problematic when token is linked to current session"
>> I knew about that. When I first started writing the generator it was just extending the webservice_server abstract class (containing only authentication), and so had the exact same authentication. Any ws user has a password, so should be able to authenticate with ws.
"6/ missing login fault logging and lockout (not implemented in standard WS yet too) (security)"
>> another good point, 'll write another issue for that.
"7/ this approach does not give access to docs if WS are not configured"
>> I think it's a good approach. We can write an additional documentation page listing all web service (with PDF to download)
in an additional 8/, we need an easy printable form.