[isf-wifidog] WiFiDog Roadmap, first draft

Benoit Grégoire bock at step.polymtl.ca
Mar 28 Juin 18:18:08 EDT 2005

On June 21, 2005 01:30 pm, Gabe Sawhney wrote:
> There's been little discussion about Benoit's roadmap except for the
> mysql support issue.  You guys had a meeting on the 14th, I think --
> what was the result?
> WirelessToronto's priority right now is content.  I'm happy to see
> François <http://old.ilesansfil.org/wiki/Fran%c3%a7oisProulx>'
> documentation on the content distribution system, but I'm still really
> confused by it.  It's be particularly useful if someone who understands
> it could write a "walkthrough" simply describing how to post content
> (even just a chunk of html) on a portal page... I fiddled with it for a
> while, with only moderate success.  If our developers here can get a
> good understanding of it, we'll surely contribute towards improving the
> documentation and/or interface to make it easier to use.

We definitely need to write a walktrough for simple cases.  However, I don't 
know when someone will get to it.  In the meantime, here's the walktrough for 
your simple request:

1-Go to the administration page
2-Click on Content manager
3-Click "Add new Content"
4-Select "Langstring" as ContentType
5-Save the Content.
6-In the Title section, select content type "TrivialLangstring" and click add.
7-Give it a title
8-Make sur the box "Is persistent" is checked
9-Type or copy paste your HTML fragment in the last field at the bottom.
10-Save the Content. 
11-(Optionally, Preview Content here)
12-In the left menu, select the node you want to add it to and click edit
13-In the "Node content" section, find your content and click add
14-use "Preview Node" to check that it worked.

If it all seems convoluted, it's because for now the preferred way to add 
content is through a Content Group, and because the interface to directly add 
Content from a node hasn't been written...

As for why you had little success before, it's because there was a bug in the 
Langstring class preventing you to make it persistent, so the only way to add 
a string wat through a content group:( I discovered it while writing this, 
and it's now fixed in CVS.

> Other priorities for us:
> - Including (average) session lengths in the reports pages.  This is an
> essential stat for PR purposes.  (How is logout time determined?)

After 5 minutes (I'm not sure the exact number) of inactivity, the gateway 
sends a logout event to the auth server along with final connection 

Note that the statistic you want is probably the average total length of daily 
usage per day a user connected, since most users will use the service more 
than once.
> - Giving users the ability to get back to the portal page after having
> left it.  My thought was to build a little app to put on
> wirelesstoronto.ca which would check to see if visitors' IP address
> matches with any of the last_heartbeat_ips in the nodes table -- if it
> does, then include a link saying "Welcome to hotspot X! Click here for
> the portal page."  Or somesuch.  It doesn't need to be 100% reliable, it
> just needs to work most of the time.

All the basic functions to implement this are already there, it's even less 
work than you think.  There is already a RFE on it:  

Note that this will have to wait till after the feature freeze.

> - MAC address whitelisting.  (My interpretation of this: on a
> hotspot-specific-basis, certain specified MAC addresses would be
> identified by the router as "friendly" and automatically logged in,
> without being redirected to the login or portal pages.)  It'd be ideal
> if this was launched in conjunction with the previous feature, to make
> it simple for these users to get to the portal page if they wanted.  I'd
> like to offer this functionality essentially just to hotspot owners.

Actually that was per-user MAC address whitelisting.  
However, it's quite trivial to add it per hotspot as well once the mechanics 
have been written.

> - We're considering requiring that "remote" users must log in in order
> to see the portal page of a hotspot if they're not physically at that
> spot.  (Are there any major reasons not to do this?  Would this be very
> difficult?)

It wouldn't be difficult, there are reliable functions to test this.  The 
reason we didnt do it is for ease of debugging.  In order for that feature to 
be acceptable, administrators should be excluded from it.

> - Another angle on the above: some stuff shouldn't appear on portal
> pages if you're logging in remotely.  In particular, it'd be nice if the
> list of users currently logged in was only accessible locally -- it's a
> bit creepy otherwise.

I suspect there could be a debate on this, but if it's configurable per 
network, it's a good idea. 

> - It'd be nice to streamline the user signup / validation / login
> process a bit (ie, automatically loggin people in once they've created
> their account).  Especially to address the problem of accidental
> "virtual" logins.  I have no idea how this part works yet.

It's partially solved, but there are still several usability bugs in there.

These are all good suggestions, don't hesitate to open bugs or RFE on them.  
Code is also very much appreciated...

Benoit Grégoire, http://benoitg.coeus.ca/
-------------- section suivante --------------
Une pièce jointe non texte a été nettoyée...
Nom: non disponible
Type: application/pgp-signature
Taille: 189 octets
Desc: non disponible
Url: http://listes.ilesansfil.org/pipermail/wifidog/attachments/20050628/efe59d15/attachment.pgp

More information about the WiFiDog mailing list