Difference between revisions of "Talk:Ackis2.0/Protocol"
From Makers Local 256
(discussion on protocol additions including auth and general information querying involving the core) |
(→resources: new section) |
||
| Line 1: | Line 1: | ||
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. | ||
Revision as of 22:15, 20 July 2008
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.
