Difference between revisions of "Talk:Ackis2.0/Protocol"
(discussion on protocol additions including auth and general information querying involving the core) |
(add discussion on component transactions) |
||
| (One intermediate revision by one user not shown) | |||
| Line 1: | Line 1: | ||
| + | == auth == | ||
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. --[[User:Opticron|Opticron]] 22:49, 10 July 2008 (CDT) | 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. --[[User:Opticron|Opticron]] 22:49, 10 July 2008 (CDT) | ||
| + | |||
| + | == resources == | ||
| + | |||
| + | 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. | ||
| + | |||
| + | == component transactions == | ||
| + | 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". --[[User:Opticron|Opticron]] 00:46, 26 April 2009 (CDT) | ||
Latest revision as of 00:46, 26 April 2009
auth
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)
resources
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.
component transactions
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)
