I don't know how we want to do authentication for remote (or local) users. I'd imagine it would use a hashing function like MD5 or SHA1 on a concatenation of the responseid, username, and password in a defined order. Probably an "authenticate" tag. Instead of implementing a specific "component" tag, we should probably create a more generic "information" tag in which you can query the core for data about its internals. --Opticron 22:49, 10 July 2008 (CDT)
Are resources allowed to utilize other resources? This would prevent resources from being included in the message family of transactions. I think it should be its own tag anyway, because the transactions serve a fundamentally different purpose from typical messages.
Currently, it is specified that the core must support action=list with type=actions and type=types. A better convention would be to only require action=list with type=actions. All other meta-info queries to get information about a specific action should be requested using action=list with type=<action>. As such, to find out what types you can use with the list action, you would do action=list with type=list and get back "list,actions" at bare minimum. A more complete core might respond to the same query with "actions,list,components,modules,clients,resources,connections". --Opticron 00:46, 26 April 2009 (CDT)