[isf-wifidog] R&D director report

[Benoit Grégoire]

As agreed, every director is supposed to write a report of what transpired in 
this departement since the last general meeting, here is mine:

I met with Mike to try and arrive at an mutual understanding of what we need 
to start accumulating content for the portals.  The technical implications of 
these are to give priorities to:

-Profiles (Philippe started working on it)
-Minor changes to Flicker to allow displaying only the last image but bigger, 
and possilby a second but random one. (François)
-Allow an option to extend the RSS feed content by default (to be used when we 
only show two or tree articles) (Me).
 
----------------------------------------------------
There was also meeting of the wifidog developers last Sunday.  Here's a quick 
summary of each subject discussed:

> -Communication entre développeurs maintenant que wifidog est mondial.

Not specifically discussed.

> -Roadmap gateway
>         -Retour sur les objectifs architecturaux du gateway établis lors de 
la 
> première réunion.
>         -Les quatre use case de traffic shaping (voir les RFE sur 
sourceforge)

The consensus was that the algorithms I sent in a prior email (in french) to 
solve the four cases were sound, but would not be implementable as described 
because:
-The current bandwidth passing trough the upstrem connection cannot always be 
known by the system as it can be affected by external factors.  While this is 
unavoidable, the algorithms must not degrade in a pathological case when the 
estimation is wrong.  More research must be done into this area.
-As philippe pointed out, if we call tc for each user and the re-adjust each 
one individually to meet changing conditions, the forking overhead will kill 
us on the WRT54G (if nothing else kills us that is).  We will have to find a 
way to chain the existing queing strategies in the kernel to do the dynamic 
work locally, leaving only the general policies updated by the central 
server.  Fortunately tc seems very flexible in this regard.

>         -WPA

Consensus that it is definitely a disireable feature, but no one at ISF will 
commit actual time developing it.

>         -Conditional compile of extra features

This is for the gateway.  A consesus was reached that there would be core 
features and extensions.  Extensions will be compile time options (using 
autoconf), avoiding the overhead of dynamically linking modules.  A small 
configure help script will be written to list and enable/disable them.

-Serving local splash page will be a core feature, so that there is a fallback 
when all auth servers are down.
-The current uptime and memory usage sent by the gateway will become an 
extension.

> -Mettre le roadmap sur SF drette la, pas plus tard.

There weren't enough details yet to make it into a roadmap.

> -Architecture de plugins sur le auth server

Plugins (Content, authenticator, geocoders) will be slightly changed:
-Each plugin will have a folder named ClassName, and a class file also named 
ClassName.php.  Thi will allow us to profide readme's for extensions, as well 
as additional files.
-Plugins will still be distributed as part of the main auth server, for schema 
handling and translation considerations.

> -Nouvelle approche CSS et Smarty (découle des discussions à Londres et avec 
> Philippe), gestion du positionnement du contenu et des outils dans 
> l'interface.

CSS was not really discussed as Benjamin had to leave early.

Smarty was discussed very extensively.  While not everyone is happy with that 
solution, the "macro-template" approach was chosen since no viable 
alternative was presented.  This means that there will Smarty templates 
providing the glue for data and html generated by various parts of the 
system.  Avoiding adding code duplication will remain a major goal in the 
rework.

> -Comment terminer de dé-ISFer le auth server, et qu'est-ce que ça a comme 
> implication?

Very lightly touched on, no real discussion.  The idea is to create singleton 
content types in the Content manager to represent "tools".  In conjunction 
with the CSS rework, this will allow groups to move (or remove) things like 
the online user list, the login form, without having to modify any file under 
version control.

> -Adopt a hotspot (manque pas grand chose, faudrait finir)

Will be finished "Real soon now".

> -Quotas pour les usagers, comment on les gère

Will be mostly dealt with at the node level. The user will be informed of the 
remaining bandwidth.
 
> -Granularité des permissions sur le auth server
> -Passer au travers des listes de bugs (11) et RFE (21)
> -Fichiers plus ou moins deprecated, où les envoie-t'on?

Ran out of time to discuss this.
---------------------------------------------

-- 
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/20051109/f55ea4b8/attachment.pgp