[Web-SIG] SIG charter

[Michael C. Neel]

On Fri, 2004-08-27 at 13:51, A.M. Kuchling wrote:
> On Fri, Aug 27, 2004 at 06:26:05PM +0100, Ben Sizer wrote:
> > Does the suggestion in the Web-SIG charter no longer hold true then? I'm 
> 
> I think the charter was written by Bill Janssen, who doesn't seem to
> be actively participating on the list any more.  The charter doesn't
> necessarily bear any relevance to what the individuals in the SIG are
> actually doing.
> 

When first started, there were alot of ideas thrown about, but I think
there was also alot of 'sniping' going on, which led to a very quiet
period on the list.  I don't think most are here to fight for ideals,
just to write code and solve some common problems.

The current charter is too narrow in focus, and carries a slight bias
tword suggested solutions.  If I were asked what I think the charter
should say, it would be along the lines of reviewing, updating, and
adding modules to the python standard library that related to the web
and web based technologies, and at the same time defining recommended
standards around these technologies.

The list is doing the latter, but not the former, which is a shame. 
There are several "common domain" problems that could be addressed, but
aren't.  One example is cookies, there is a python stdlib module for
cookies and yet mod python has it's own cookie module -- this points to
a reason to review the stdlib module because it isn't providing what is
needed to mod python.  Considering any framework will need to address
cookies, this is something that makes sense to address on a Web SIG.

There have also been ideas for servers and clients in the stdlib (which
there already are some, so they would be built upon and expanded) and
even a mention of python applets.  I think all of these should also fall
into the Web SIG charter, and at least merit discussion.

I think the WSGI is a good concept and idea, but not a burning issue. 
In practice, I have never had the need to port an application /
framework across servers and platforms.  If that was part of the scope,
it was along with a complete rewrite so I really didn't want to keep the
prior application's code and possible it's framework.  Also, many
frameworks have placed the server specific code into a controller class
that can be quickly subclassed and taken to a new server.

Mike