[isf-wifidog] Wifidog development

[François Proulx]

Hi Sam,

As a general manner, we like to start with patches. Once you get used  
to the code, you'll probably be given a repository access.

> Some ideas I have:
>
> 1) enhancements to the hotspot map. Integrations with google local,  
> so if the business address matches google local, a search could be  
> done of restaurants, and it would return all restaurants on the  
> wireless hotspot map, same with inns/hotels, etc...

I'd suggest you create a plugin, although I have to admit it won't be  
trivial since it's mostly Javascript code ... We'd rather not  
integrate directly code that relies on third party data in the  
mainline. But if you can think of someone that can be enable/ 
disabled, we'll be happy to add it.

> 2) localities, I'm not sure if this is what networks could be used  
> for, but it seemed the network list showed up for all networks at  
> every hotspot, let me know if I'm wrong with this. By localities, I  
> mean city1.domain.com and city2.domain.com, where the hotspot map  
> for city1 would zoom around city1, and city2 would zoom around  
> city2, then domain.com hotspot map would zoom out to show all  
> localities. Then the default splash for all nodes with city1 would  
> tailor to the city (ie. A victorian historic district would have  
> images of historic buildings on the login and splash page, and a  
> football town, would have logos for the team)

Right now, this would be dealt using a Wifidog "network" for each  
city. If I understand what you're looking for, most of what's needed  
is there. I'd suggest you play around we the networks and see what's  
missing / has to fixed to meet your proposition ...

> 3) Locality administrators. This would require a database change I  
> think. Basically a username would need to have an array of  
> localities it administers, so it could change things for that given  
> locality.

Right now we have global administrators, node owners and technical  
officers, we plan to improve the granularity of the user rights.  
Again, your concept of "locality" should be dealt using "networks" so  
once we create administrators that are tight to a given network you  
should be good to go. If you want to work on that part get acquainted  
with this part of the code and send us patches first.

> 4) Node user management. This is a little more tricky. This way, if  
> John Smith is abusing node_1, the manager of the node could block  
> him from node_1, but he'd still be able to access other nodes.

Should be trivial, but since one can create free accounts just by  
getting a new free e-mail account ... it won't harm the abuser at all.

> 5) mac address blocking from auth server. This way a known abuser  
> can't create a new user. maybe timed, so an abuse expires after a  
> month.

Not only should we add blocking by MAC, but we shall add  
whitelisting, because some devices that here plugged to our routers  
need to access the Internet at all times (right now we manually  
configure each router). I'd recommend you start working on this  
feature before you work on the others.

> Also, in regard to these ideas, do you think they'd be better as  
> part of the base of it, or modular where they can be enabled or  
> disabled by the user?

depending if it's already in the roadmap for version 1.0, you should  
integrate it in the mainline. If you have contributions that are more  
specific to your network, but would probably benefit to others, then  
you should create plugins (whenever it is possible)