[isf-wifidog] Re: [wirelesstoronto-discuss] devauth up now

Benoit Grégoire bock at step.polymtl.ca
Jeu 3 Nov 12:01:18 EST 2005


> Hey Rob,
> 
>  Those are all excellent points. I liked some of your questions that
> should be posed to the group like: "what are we?  lurkers/consumers vs
> contributors" (I hope we can be contributors as well as consumers).
> 
>  I was fortunate to have been privy to a new direction ISF and NYC has
> already agreed upon but I'm not certain that it made it out to our
> list (or may have passed by under the radar). Specifically, regarding
> customizations: the desire for customizations is largely for layout
> purposes. In instances where we have dreamed up functionality (like
> googlemaps), ISF contributors have beat us to the punch and
> implemented it. As part of the main cvs, the functionality will
> benefit all without having to resort to a fork that may be missing
> other functionality that is desirable for a given site. We want to
> contribute new functionality to the whole and not fork (for the
> benefit of everyone).

snip

>  Our customizations would largely happen within the site.css (or
> server customized css). Any new functionality (free of styling) that
> we desire to produce would, I'm sure, be very welcome in the Main
> repository. The only instance where forking would happen is if we
> wanted functionality or changes that the other wifigroups didn't want
> - in which case, I would hope that would be enough reason to
> reconsider the value of such functionality or changes to code.
> 
>  I believe that if we resist the urges to fork, concerted efforts will
> make Wifidog into something truly amazing in short order. It is
> already pretty damn impressive if you think about it.

We are REALLY glad to see you feel that way!  We were worried you were 
institutionalizing a development process that would make it extremely hard 
for you to contribute patches back.  We really are trying to bend over 
backwards to make wifidog as generic as possible, which is a huge amount of 
additional work for us at this time.  It's will be worth it if it allows 
people to use the mainline distribution mostly unaltered.  Unfortunately, 
right now this process is incomplete and we are sorry if it's not really 
obvious to other groups exactly how we plan to solve all this (it definitely 
isn't if you are not on the wifidog mailing list).  But we do have a plan, 
and the CSS/layout issue is actually the easy part of the problem.

Believe me, while it's not obvious when you start, in the end it will be much 
easier for you to stay close to mainline and help us fix rough areas in the 
content manager that re-doing the customization engine on your own without 
it.  Maintaining per-hotspot templates becomes unscalable very quickly.  The 
original local content system was mostly like the one some of you seem to be 
re-creating.  We moved away from that because it didn't work out.

It's unfortunate that the content manager is almost completely undocumented 
and that little attention was put on the admin UI.  Creating layout to 
present information that varies in nature and size is really hard, and is 
more of a semantic problem than a layout one.  Solving the first one makes 
deciding on semantic HTML structure trivial. 

One a little note on that.  The auth server isn't supposed to be a CMS.  It's 
even clearer after the conference in London.  It's has to be a content 
presentation engine, do that well, and not try to be a CMS in the tiki-wiki 
sense.  While it's unavoidable to allow it to swallow simple content types 
(images, descriptions and the like), the primary way to use it is to pull 
content from other sources.  For example there will probably never be an 
event manager in wifidog.  However there will be an iCal client.  Just like 
now there is no news database (which would be trivial to implement), but 
there is one of the most flexible RSS aggregator available (which is a lot 
harder).

The Content manager was born out of a need to solve the problem of localized 
content in a more generic and complete way.  It saves time on maintenance 
(among other things, content is automatically migrated when there is a new 
version), and allows you to automatically rotate content so that users don't 
get bored by the portal (well, that also requires assembling a sizeable 
corpus of interesting content, but that is a separate problem) .  From our 
discussion in London, there seems to be a consensus that it's also the best 
way for each group to use a portal in very different ways without maintaining 
sets of patches.

I don't expect you all to believe it right now, but I would humbly ask you to 
move your discussions of the issues you have with wifidog (layout or 
otherwise) to the wifidog mailing list: 
http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
And also, to use the bug tracker for bugs and feature requests:
http://sourceforge.net/projects/wifidog

Most of the issues I've seen on your list are shared by other groups 
(including ISF), have been discussed before, and have planed solutions.  We 
will welcome any specific suggestions with open arms.   It will be less work 
for both of us, will get the changes you need in the mainline faster (less 
maintenance for you), and provide us with an additional external point of 
view.  As we finish "De-ISFing" the auth server, it will become increasingly 
hard for us to spot remaining areas that are not generic.

We really hope to hear from you directly!

Benoit Grégoire
Île sans fil
-- 
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/20051103/25e74f00/attachment.pgp


More information about the WiFiDog mailing list