-- XMLRPC is fine. It's sad there are a lot of cool tools that support neat SOAP stuff with WSDL (Visual Studio, I hear) but SOAP is bloated enough that I'm not enthusiastic to support it.
-- I don't want to use /interface/xmlrpc, mostly because I want to easily load balance this to an entirely separate several with its own web server and database. Also, I imagine we should support a "REST" (hate that name) API and SOAP in the future, so let's not put XMLRPC in the name. You guys can come up with a new name.
-- Optimization-wise (to reduce database calls), it'd be easier to support a comma-separated list of usernames for each method, rather than using system.multicall(), and then the results of that method are returned once per user, inside a per-user element. I imagine we could analyze all the multicalls and join them, then split them later, but that seems a lot of work. However, we could still use system.multicall() in addition (if you wanted to call multiple methods), but I'd say we also support comma-delimited parameters.
-- Require no authentication, but require users to specify their authentication type: anonymous, lj user, or developer server token bound to an IP (which we could give out for really high-volumne users, so they're detected as idiot spiders without caching). We'd never return email addresses to anonymous queries, either, only when authenticated and a friend, probably.
We have an extra server ready to put this up with web/db stuff ready on it, so let's get this going soon. Because it'll be isolated, we can upgrade/stop/start it often and get a fast release/testing cycle going.
So, continue your discussions, but maybe focus initially on a few methods which we can get up already:
This week: :-)
get_friendofs (each of which would return rich structures, including name/acct type/etc)
get_supportpoints (for a user(s))
get_supportboard (including categories, colors, etc)
(And I imagine we could just drop the get_ prefix, since they'll all be get?)