Changes between Version 2 and Version 3 of doc/developer/WiFiDogProtocol_V2

Show
Ignore:
Timestamp:
03/25/08 22:52:15 (14 years ago)
Author:
papril
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • doc/developer/WiFiDogProtocol_V2

    v2 v3  
    1515That pretty much leaves only two options:  YAML and XML, with YAML matching them more closely. 
    1616 
     17> Philippe: experienced with JSON, and it's great (great parser/generator for C). See [wiki:doc/developer/WiFiDog_V2] 
     18 
    1719== Request format == 
    1820It is beyond desirable to have to following with request format: 
     
    2224Some of the requirements above do not lend itself well to a RESTFull Resource oriented architecture (ROA).  However, keeping the current format (GET parameters) limit us, in practice, to a single list of tag-value pairs.  Even if one could, in theory, put an action=whatever in the middle of the list and have the protocol decree that every following parameters (until the next action) is to be a parameter of that action, that would utterly confuse most web servers and frameworks. 
    2325 
    24 One other possibility is to borrow a page from the way PHP does URL-parsing. Setting the key part of the get request to a array representation would allow for fairly logical request bundling., I.e.: 
     26> acv: One other possibility is to borrow a page from the way PHP does URL-parsing. Setting the key part of the get request to a array representation would allow for fairly logical request bundling., I.e.: 
    2527 
    2628{{{ 
     
    3032}}} 
    3133 
    32 This format would remain human readable while being very simple to parse (free in PHP, trivial in other languages). 
     34> acv: This format would remain human readable while being very simple to parse (free in PHP, trivial in other languages). 
    3335 
    3436So POSTing the parameters may have to be considered, in which case the same format as the response should be used, for obvious reasons.  
     
    3739 * Allow some general configuration changes to be sent by the auth server. 
    3840 * Allow non web-based MAC auth 
     41 > Philippe: Explain this? 
    3942 * Allow non connection based MAC auth 
    4043 * Allow per-connection firewall policies 
    4144 * Allow per-connection bandwidth management, not limited to set amounts 
     45 * Allow global bandwidth management (might come in configuration) 
    4246 * Many more.... 
     47> Philippe: Ideas? 
     48 
     49> Philippe: Way to allow people on restart, or deny people on inactivity 
    4350 
    4451= Actions = 
    4552== NOOP == 
    4653Basically there only for gateway heartbeating.  A min delay between operations would be specified, and if this delay is reached before an actual operation has to be performed, a NOOP is sent. 
     54> Philippe: not required, we'll always send at LEAST the status. If no "command" is sent, it means NOOP :) 
    4755== AUTH_VERIFY == 
    4856== STATS_UPDATE == 
    4957 
     58= A proposed solution = 
    5059 
     60> Philippe: 
     61{{{ 
     62I think we could have a Hash kind of structure like this: 
     63 
     64 * protocol_version: 1 (start with this to identify protocol) 
     65 * wifidog_version: ... 
     66 * status: 
     67   * uptime, etc. 
     68 * connected_clients: 
     69   * stats, etc. 
     70}}} 
     71 
     72and a sample reply 
     73 
     74{{{ 
     75 * protocol_version: 1.... 
     76 * config: 
     77  * loginurl: https://..... 
     78  * portalurl: http://... 
     79  * timers:... 
     80  * global bandwidth settings 
     81 * clients_that_should_be_allowed: 
     82  * { mac: xxxxxxxxx, ip: xxxxxxxx, bandwidth settings}, 
     83  * { mac: yyyyyyyyy, ip: yyyyyyyy, bandwidth settings} 
     84}}} 
     85