naviserver-devel — Developer discussion

Re: [naviserver-devel] codestyle

[Zoran V. <zv...@ar...>]

Am 14.06.2005 um 09:31 schrieb Stephen Deasey:

>
> I think this page needs some love:
>
> http://naviserver.sourceforge.net/wiki/index.php/Code_Standards
>
>

I will take the freedom to update each and every page I visit
to conform to the code-style as above.
I find the style pretty clean and simple and there should be
no problems in following it. I will also add to the style-doc
as I walk thru sources, if I find something missing or too ambiguous.

Zoran

Re: [naviserver-devel] website

[Stephen D. <sd...@gm...>]

On 6/14/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 14.06.2005 um 09:19 schrieb Stephen Deasey:
>=20
> >
> > They do.  I wasn't sure how hard it would be to set up, so I gave it a
> > try.  Behold: http://naviserver.sourceforge.net !  It wasn't so hard.
> > The source is checked into CVS:
> > http://cvs.sourceforge.net/viewcvs.py/naviserver/website/htdocs/wiki/
>=20
> Is there a word on MediaWiki on the SF site where you got the info
> how to set it up?


There is, but I didn't see it until after I completed the install...

You'll want to look at the Source Forge docs to see how the project
web hosting works:

http://sourceforge.net/docman/display_doc.php?group_id=3D1&docid=3D4297

The install of Mediawiki is pretty easy -- the INSTALL doc in the
tarball is short and it comes with a web interface where you fill in
some forms and  it creates the config file for you.

Here's the Source Forge specific installation docs:

http://meta.wikimedia.org/wiki/Running_MediaWiki_on_Sourceforge.net

Re: [naviserver-devel] website

[Zoran V. <zv...@ar...>]

Am 14.06.2005 um 09:19 schrieb Stephen Deasey:

>
> They do.  I wasn't sure how hard it would be to set up, so I gave it a
> try.  Behold: http://naviserver.sourceforge.net !  It wasn't so hard.
> The source is checked into CVS:
> http://cvs.sourceforge.net/viewcvs.py/naviserver/website/htdocs/wiki/

Is there a word on MediaWiki on the SF site where you got the info
how to set it up?

Zoran

Re: [naviserver-devel] binder, sockets

[Zoran V. <zv...@ar...>]

Am 14.06.2005 um 09:45 schrieb Stephen Deasey:

> I don't understand why listen() is not called.  You have to do this in
> order to receive connections, right?


Eh... Vlad should answer that :-)

All I did was cosmetically cleaning up the code w/o actually
going into the functionality. I did not want to change anything
functionality-wise until he looks over it.

Zoran

Re: [naviserver-devel] binder, sockets

[Stephen D. <sd...@gm...>]

On 6/13/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 13.06.2005 um 09:37 schrieb Stephen Deasey:
>=20
> >
> > Ns_SockListenTcp() should probably replace Ns_SockListenEx() with it's
> > backlog parameter?  The passed backlog should be checked, and if it's
> > < 1, use the default from the config file.
> >
> > If this is the new recommended way to listen on sockets, I'd update
> > all callers of the old Ns_SockListen(Ex) functions.  People will cut
> > 'n paste old code and continue the confusion.
>=20
> Well, I have left the Ns_SockListenEx() untouched. We might rename
> it to Ns_SockListenTcp() to be more consistent but I did not want
> to do that yet because I do not know what side-effects this may
> have.
>=20
> >
> > Hmm, Ns_SockListenUnix() doesn't actually call listen().  Is this
> > right?  Also, is a backlog parameter appropraite here, as in
> > Ns_SockListenEx()?
>=20
> No, it does not. It just binds.
> As well as the raw sockets; Ns_SockBindRow does not bind.
> It just creates the socket.


I don't understand why listen() is not called.  You have to do this in
order to receive connections, right?

Re: [naviserver-devel] codestyle

[Zoran V. <zv...@ar...>]

Am 14.06.2005 um 09:31 schrieb Stephen Deasey:

>
> I think this page needs some love:
>
> http://naviserver.sourceforge.net/wiki/index.php/Code_Standards
>

And I think that you are absolutely great!

Zoran

Re: [naviserver-devel] Move nscgi to modules?

[Stephen D. <sd...@gm...>]

On 6/13/05, Vlad Seryakov <vl...@cr...> wrote:
> Yes, i agree nscgi should be in the core.
> Regarding nsdb, until new dbi interface tested and we have enough
> drivers i would keep nsdb in the core. It is very important module.


Yeah, that's what I thought.

I noticed the postgres driver implements the old database
introspection routines, listing tables etc.  I thought moving that
back into nsdb might simplify things.  It would be nice to track those
changes in nsdb's own ChangeLog.  No rush though.

Re: [naviserver-devel] codestyle

[Stephen D. <sd...@gm...>]

On 6/13/05, Zoran Vasiljevic <zv...@ar...> wrote:
> Hi !
>=20
> I would like to see if we can agree on the style used when
> formatting source-code.
>=20
> What I find very annoying is the usage of the TAB. According
> to both AOL and TCL style-guides, the TAB is deprecated.
> Now, in the Tcl project, it is still used, which I do not
> really understand??
>=20
> The problem with TAB's is: if you have some other TAB-width
> set then 8 spaces, the format looks pretty desperate and difficult
> to follow.
> OTOH, if you expand TABS to spaces, then normally you can read the
> code regardless of your current TAB width.
>=20
> I would suggest we avoid using TAB's for formatting and use plain
> spaces instead. I have setup this in emacs to expand TAB's to
> spaces always.
>=20
> What do you think?


I think this page needs some love:

http://naviserver.sourceforge.net/wiki/index.php/Code_Standards

Re: [naviserver-devel] website

[Stephen D. <sd...@gm...>]

On 6/13/05, Bernd Eidenschink <eid...@we...> wrote:
> > > Until direct login is possible for you please send me any content you
> > > like to add, see, change!
>=20
> I forgot to mention that this is just because we decided to rewrite the
> frontend display stuff so that it uses tdom/xml/xslt and now just have to
> bring our existing cms forms step by step into the xslt world :-)
>=20
> Nothing against a Wiki, nothing against templates, nothing against even a
> totally different homepage look if you like.
>=20
> I just like the idea of having a project homepage that actually runs the
> software it promotes and somehow can imagine situations where a little bi=
t
> more control or programming power (TCL/Naviserver) would be nice to have.


The thing is, our website isn't the best vehicle for showing off what
the software can do because the requirements of our website are
minimal.  One of the most important things is that we're able to just
forget about it and get on with developing the software.

It would be really nice to have some info on the website showing how
people are using the technology in real projects.  Some code examples
and behind the scenes info would surely interest people more than the
finished, redered page.


> Importing documentation should be no problem, also exporting can be done =
via
> xml. What about discussion boards or newsletters with Wikis? We can provi=
de
> such apps, xslt-comments from above apply.


Source Forge provides news and discussion forums.  I turned off the
forums to keep the tiny user base all on the mailing list.  We've had
no news, as yet  :-)


> On the other hand I can understand if you all like more direct control ov=
er
> that stuff as would the Sourceforge solution provide.
>=20
> May the majority decide!
>=20
> Bernd.

Re: [naviserver-devel] website

[Stephen D. <sd...@gm...>]

On 6/13/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 13.06.2005 um 17:19 schrieb Zoran Vasiljevic:
>=20
> > What infrastructure would be needed to run MediaWiki?
>=20
> Ehm:
> Prerequisite tools
>=20
> To install MediaWiki you need four components:
>=20
> MySQL - an SQL database to store the Wiki text, user list etc.
> Apache - a web server to serve the HTML web pages
> PHP - the programming language that MediaWiki is written in. Fedora/
> Redhat users will also need the PHP-Mysql package.
> MediaWiki itself, which is a suite of programs written in PHP
>=20
> I do not know where should we get all these things?
> Does SourceForce offer this is part of their services?


They do.  I wasn't sure how hard it would be to set up, so I gave it a
try.  Behold: http://naviserver.sourceforge.net !  It wasn't so hard.=20
The source is checked into CVS:
http://cvs.sourceforge.net/viewcvs.py/naviserver/website/htdocs/wiki/

I still need to set up an auto-update script to cvs up the website
every hour or so.

I configured it so that you have to log in to edit pages.  If y'all
create accounts with your sourceforge name I'll give you sysop privs,
with which you can delete pages, ban users etc.

So, have a play with it, see if you think this will work for us.=20
There's some documentation on the software here:
http://meta.wikimedia.org/wiki/MediaWiki_FAQ

[naviserver-devel] Tcl/Tk 2005 Second Call for papers

[<aku...@sh...>]

Submission of Summaries

Tcl/Tk 2005 will be held in Portland, Oregon USA from October 24 -
October 28. The program committee asks all people using and developing
with Tcl/Tk and extensions to submit papers and proposals for
presentations at this conference. Past conferences have seen
submissions covering a wide variety of topics including and not
limited to:

    * Scientific and engineering applications
    * Industrial controls
    * Distributed applications and Network Managment
    * Object oriented extensions to Tcl/Tk
    * New widgets for Tk
    * Simulation and application steering with Tcl/Tk
    * Tcl/Tk-Centric operating environments
    * Tcl/Tk on small and embedded devices
    * Medical applications and visualization
    * Use of different programming paradigms in Tcl/Tk and proposals
      for new directions.
    * New areas of exploration for the Tcl/Tk language 

The submissions should consist of an abstract of about 100 words and a
summary of maximum two pages. Omit extraneous or redundant
information. Length is not a direct factor in judging the quality of
the submission.

Send submissions as plain text to <tcl2005 AT tcl.tk> no later than
July 1, 2005. Authors of accepted abstracts will have until September
15, 2005 to submit their final paper for the inclusion in the
conference proceedings. The proceedings will be made available on
CD-ROM, so extra materials like code samples are welcome.

The authors will have 20-25 minutes to present the paper at the
conference.

The program committee will review and evaluate papers according to the
following criteria:

    * Quantity and quality of novel content
    * Relevance and interest to the Tcl/Tk community
    * Suitability of content for presentation at the conference 

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreement forms will be returned
to the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

Other Forms of Participation

The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.

Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis
starting in August, 2005. Specific instructions for reserving WIP and
BOF time slots will be provided in the registration information
available in June 2005.  Some WIP and BOF time slots will be held open
for on-site reservation, so we encourage all attendees with
interesting work in progress to consider presenting that work at the
conference.  Registration Information

More information on the conference will be available in April 2005 at
the conference Web site and published on various Tcl/Tk-related
information channels.

To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list.

Conference Committee

Brian Griffin   	Mentor Graphics	      Facilities Coordination
Clif Flynt	   	Noumena Corp	      General Chair, Website Admin
Ron Fox     		NSCL MSU              Program Chair
Arjen Markus   		WL Delft Hydraulics	
Cyndy Lilagan   	Eolas Corp	
Gerald Lester   	HMS Software	
Donal Fellows   	University of Manchester	
Jeffrey Hobbs   	ActiveState Corp	
Steve Landers   	Digital Smarties	
Kevin Kenny   		GE Global Research Center	
Ken Jones   		Avia Training	
Sheila Miguez   	mVerify	
Larry Virden   		Tcl FAQ Maintainer	
Andreas Kupries 	ActiveState Corp	

Contact Information <tcl2005 AT tcl.tk>


--
Sincerely,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

Re: [naviserver-devel] website

[Zoran V. <zv...@ar...>]

Am 13.06.2005 um 17:19 schrieb Zoran Vasiljevic:

> What infrastructure would be needed to run MediaWiki?

Ehm:
Prerequisite tools

To install MediaWiki you need four components:

MySQL - an SQL database to store the Wiki text, user list etc.
Apache - a web server to serve the HTML web pages
PHP - the programming language that MediaWiki is written in. Fedora/ 
Redhat users will also need the PHP-Mysql package.
MediaWiki itself, which is a suite of programs written in PHP

I do not know where should we get all these things?
Does SourceForce offer this is part of their services?


Zoran

Re: [naviserver-devel] website

[Zoran V. <zv...@ar...>]

Am 13.06.2005 um 10:00 schrieb Stephen Deasey:

> On 6/6/05, Bernd Eidenschink <eid...@we...> wrote:
>
>>
>> Hi,
>>
>> _please_ excuse the delay for bringing up the homepage. There is a  
>> first
>> version at www.servercult.com now.
>>
>
>
> Don't worry about it, it took me just as long to reply...  :-)
>
>
>
>> Feel free to bring up everything you like or dislike. This is just  
>> a proposal
>> (and also work in progress).
>>
>> In my opinion some very basic texts describing the 'why' and  
>> 'where to go' of
>> the project should be made available for the community; also I  
>> agree with you
>> to keep the content low to focus work on the more important areas!
>>
>> Until direct login is possible for you please send me any content  
>> you like to
>> add, see, change!
>>
>> Regards,
>> Bernd.
>>
>
>
> How does everyone feel about using a wiki?  Take a look at this:
> http://psplinux.sourceforge.net/ -- These folks are using MediaWiki,
> the software behind the WikiPedia project, on their Source Forge
> hosted web site.
>
> Now take a look at this site:  http://hula-project.org -- This is the
> exact same software with a different template running the main website
> for Novell's new Hula mail/calendar server software.  Looks nice.
>
> I've looked at MediaWiki briefly.  It comes with half a dozen
> templates which can be used as a starting point to achieve the look
> and feel that Bernd's developed.
>
> I think we'd run it slightly differently than the AOLserver wiki we're
> already familiar with.  We'd auto-generate Zoran's fancy new docs from
> CVS as static pages, maybe using the wiki for comments.  Also, we'd
> auto-generate a list of modules straight out of CVS so that it's
> always up-to-date.
>
> So, how about it?  I think it would be an easy, low maintenance way to
> get a lot of people participating quickly.
>

What infrastructure would be needed to run MediaWiki?
Do we have time/knowledge to set it up (I don't).
OTOH, the fact that everybody can freely participate (wiki)
appeals to me because it eases the burden of maintenance.

Both projects you quoted look pretty nice, BTW.

Zoran

Re: [naviserver-devel] codestyle

[Vlad S. <vl...@cr...>]

i agree

Zoran Vasiljevic wrote:
> Hi !
> 
> I would like to see if we can agree on the style used when
> formatting source-code.
> 
> What I find very annoying is the usage of the TAB. According
> to both AOL and TCL style-guides, the TAB is deprecated.
> Now, in the Tcl project, it is still used, which I do not
> really understand??
> 
> The problem with TAB's is: if you have some other TAB-width
> set then 8 spaces, the format looks pretty desperate and difficult
> to follow.
> OTOH, if you expand TABS to spaces, then normally you can read the
> code regardless of your current TAB width.
> 
> I would suggest we avoid using TAB's for formatting and use plain
> spaces instead. I have setup this in emacs to expand TAB's to
> spaces always.
> 
> What do you think?
> 
> Zoran
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you 
> shotput
> a projector? How fast can you ride your desk chair down the office luge 
> track?
> If you want to score the big prize, get to know the little guy.  Play to 
> win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] website

[Vlad S. <vl...@cr...>]

I like auto-generating idea:-)))

Stephen Deasey wrote:
> On 6/6/05, Bernd Eidenschink <eid...@we...> wrote:
> 
>>Hi,
>>
>>_please_ excuse the delay for bringing up the homepage. There is a first
>>version at www.servercult.com now.
> 
> 
> 
> Don't worry about it, it took me just as long to reply...  :-)
> 
> 
> 
>>Feel free to bring up everything you like or dislike. This is just a proposal
>>(and also work in progress).
>>
>>In my opinion some very basic texts describing the 'why' and 'where to go' of
>>the project should be made available for the community; also I agree with you
>>to keep the content low to focus work on the more important areas!
>>
>>Until direct login is possible for you please send me any content you like to
>>add, see, change!
>>
>>Regards,
>>Bernd.
> 
> 
> 
> How does everyone feel about using a wiki?  Take a look at this: 
> http://psplinux.sourceforge.net/ -- These folks are using MediaWiki,
> the software behind the WikiPedia project, on their Source Forge
> hosted web site.
> 
> Now take a look at this site:  http://hula-project.org -- This is the
> exact same software with a different template running the main website
> for Novell's new Hula mail/calendar server software.  Looks nice.
> 
> I've looked at MediaWiki briefly.  It comes with half a dozen
> templates which can be used as a starting point to achieve the look
> and feel that Bernd's developed.
> 
> I think we'd run it slightly differently than the AOLserver wiki we're
> already familiar with.  We'd auto-generate Zoran's fancy new docs from
> CVS as static pages, maybe using the wiki for comments.  Also, we'd
> auto-generate a list of modules straight out of CVS so that it's
> always up-to-date.
> 
> So, how about it?  I think it would be an easy, low maintenance way to
> get a lot of people participating quickly.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
> a projector? How fast can you ride your desk chair down the office luge track?
> If you want to score the big prize, get to know the little guy.  
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] Move nscgi to modules?

[Vlad S. <vl...@cr...>]

Yes, i agree nscgi should be in the core.
Regarding nsdb, until new dbi interface tested and we have enough 
drivers i would keep nsdb in the core. It is very important module.

Zoran Vasiljevic wrote:
> 
> Am 13.06.2005 um 10:08 schrieb Stephen Deasey:
> 
>> Yes, I mean move nsdb into modules, not remove it entirely  :-)   I'll
>> be using it myself for some time on old ACS sites that depend on it.
>>
>> The nsdbi driver interface is not compatible with nsdb.  New hooks are
>> needed to support native bind variables and prepared queries etc., and
>> I took the oppertunity to (hopefully) simplify it.  The postgres
>> driver is only ~600 lines (with comments), so it shouldn't be too hard
>> to port any of the old drivers.
>>
>> I still need to port a couple of patches to the server that nsdbi
>> depends on, and then I'll import it into modules and you can try it
>> out.
>>
> 
> I'm pretty neutral on the db stuff because we really do not
> use it at all. So, do what you think would be the best.
> 
> Apropos nscgi: ok, understand. We'll leave it in place.
> 
> Zoran
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you 
> shotput
> a projector? How fast can you ride your desk chair down the office luge 
> track?
> If you want to score the big prize, get to know the little guy.  Play to 
> win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

[naviserver-devel] codestyle

[Zoran V. <zv...@ar...>]

Hi !

I would like to see if we can agree on the style used when
formatting source-code.

What I find very annoying is the usage of the TAB. According
to both AOL and TCL style-guides, the TAB is deprecated.
Now, in the Tcl project, it is still used, which I do not
really understand??

The problem with TAB's is: if you have some other TAB-width
set then 8 spaces, the format looks pretty desperate and difficult
to follow.
OTOH, if you expand TABS to spaces, then normally you can read the
code regardless of your current TAB width.

I would suggest we avoid using TAB's for formatting and use plain
spaces instead. I have setup this in emacs to expand TAB's to
spaces always.

What do you think?

Zoran

Re: [naviserver-devel] strict aliasing?

[Zoran V. <zv...@ar...>]

Am 12.06.2005 um 11:51 schrieb Zoran Vasiljevic:
>
> Yes. Indeed. We should gradually go and fix those.
> I will do that while walking thru. You can do as well
> if at the right place.

Gradually or not gradually, I had some spare time
yesterday afternoon and have fixed all of those.
We can consider this one solved.

Cheers
Zoran

Re: [naviserver-devel] website

[Bernd E. <eid...@we...>]

> > Until direct login is possible for you please send me any content you
> > like to add, see, change!

I forgot to mention that this is just because we decided to rewrite the 
frontend display stuff so that it uses tdom/xml/xslt and now just have to 
bring our existing cms forms step by step into the xslt world :-)

Nothing against a Wiki, nothing against templates, nothing against even a 
totally different homepage look if you like.

I just like the idea of having a project homepage that actually runs the 
software it promotes and somehow can imagine situations where a little bit 
more control or programming power (TCL/Naviserver) would be nice to have.
Importing documentation should be no problem, also exporting can be done via 
xml. What about discussion boards or newsletters with Wikis? We can provide 
such apps, xslt-comments from above apply.

On the other hand I can understand if you all like more direct control over 
that stuff as would the Sourceforge solution provide.

May the majority decide!

Bernd.

Re: [naviserver-devel] still left to fix

[Zoran V. <zv...@ar...>]

Am 13.06.2005 um 08:19 schrieb Stephen Deasey:

> Now compiles clean for me with gcc 4 using flags: -02 -Wall
> -Wno-implicit-int. (Linux FC3).  Yippee!
>

Yes. On Solaris still complains about pthread_sigmask
and on Darwin about the 'long double' but this is
something we can ignore for now. When I come to that
place again, I will look into that more deeply.
For now I'm about to get the Windows part working...

Zoran

Re: [naviserver-devel] binder, sockets

[Zoran V. <zv...@ar...>]

Am 13.06.2005 um 09:37 schrieb Stephen Deasey:

>
> Ns_SockListenTcp() should probably replace Ns_SockListenEx() with it's
> backlog parameter?  The passed backlog should be checked, and if it's
> < 1, use the default from the config file.
>
> If this is the new recommended way to listen on sockets, I'd update
> all callers of the old Ns_SockListen(Ex) functions.  People will cut
> 'n paste old code and continue the confusion.

Well, I have left the Ns_SockListenEx() untouched. We might rename
it to Ns_SockListenTcp() to be more consistent but I did not want
to do that yet because I do not know what side-effects this may
have.

>
> Hmm, Ns_SockListenUnix() doesn't actually call listen().  Is this
> right?  Also, is a backlog parameter appropraite here, as in
> Ns_SockListenEx()?

No, it does not. It just binds.
As well as the raw sockets; Ns_SockBindRow does not bind.
It just creates the socket.

I did not want to add complete confusion so I followed the
TCP way:

    ListenXXX
    BindXXX

where XXX = Unix, Raw

and

    Listen
    Bind

is reserved for TCP. The only real exception is Ns_SocketListenEx
which just adds one additional (backlog) parameter.

Admitently, some calls are real misnomers as I already documented
in the funciton comment:

*
* Ns_SockBindRaw --
*
*      Create a raw socket. It does not bind, hence the call name
*      is not entirely correct but is on-pair with other types of
*      sockets (udp, tcp, unix).
*

In the process of cleanup, we might rectify/improve this and
give the calls more meaningful names.

>
>
> You can decalare Ns_BindSock() NS_GNUC_DEPRECATED and no one else need
> be confused  :-)

This is OK. I will do that.

Zoran

Re: [naviserver-devel] Move nscgi to modules?

[Zoran V. <zv...@ar...>]

Am 13.06.2005 um 10:08 schrieb Stephen Deasey:

> Yes, I mean move nsdb into modules, not remove it entirely  :-)   I'll
> be using it myself for some time on old ACS sites that depend on it.
>
> The nsdbi driver interface is not compatible with nsdb.  New hooks are
> needed to support native bind variables and prepared queries etc., and
> I took the oppertunity to (hopefully) simplify it.  The postgres
> driver is only ~600 lines (with comments), so it shouldn't be too hard
> to port any of the old drivers.
>
> I still need to port a couple of patches to the server that nsdbi
> depends on, and then I'll import it into modules and you can try it
> out.
>

I'm pretty neutral on the db stuff because we really do not
use it at all. So, do what you think would be the best.

Apropos nscgi: ok, understand. We'll leave it in place.

Zoran

Re: [naviserver-devel] Move nscgi to modules?

[Stephen D. <sd...@gm...>]

On 6/13/05, Bernd Eidenschink <eid...@we...> wrote:
> > How about nsdb?  This is an important module for people, but I'm
> > hoping my newer nsdbi will be a big enough improvement that it becomes
> > the new standard.  In that case, it's kind of confusing to ship the
> > old version.  Maybe it's something for the future.  What do folks
> > think?
>=20
> In what ways will it be different (i'm curious :-)) ?
>=20
> If the existing drivers (and api) still work with nsdbi, I would vote for
> using it and moving nsdb to the modules. So people can still use nsdb if =
they
> need to.
>=20
> As with nscgi I would vote for leaving it as some useful software still n=
eeds
> CGI.


Yes, I mean move nsdb into modules, not remove it entirely  :-)   I'll
be using it myself for some time on old ACS sites that depend on it.

The nsdbi driver interface is not compatible with nsdb.  New hooks are
needed to support native bind variables and prepared queries etc., and
I took the oppertunity to (hopefully) simplify it.  The postgres
driver is only ~600 lines (with comments), so it shouldn't be too hard
to port any of the old drivers.

I still need to port a couple of patches to the server that nsdbi
depends on, and then I'll import it into modules and you can try it
out.

Re: [naviserver-devel] website

[Stephen D. <sd...@gm...>]

On 6/6/05, Bernd Eidenschink <eid...@we...> wrote:
>=20
> Hi,
>=20
> _please_ excuse the delay for bringing up the homepage. There is a first
> version at www.servercult.com now.


Don't worry about it, it took me just as long to reply...  :-)


> Feel free to bring up everything you like or dislike. This is just a prop=
osal
> (and also work in progress).
>=20
> In my opinion some very basic texts describing the 'why' and 'where to go=
' of
> the project should be made available for the community; also I agree with=
 you
> to keep the content low to focus work on the more important areas!
>=20
> Until direct login is possible for you please send me any content you lik=
e to
> add, see, change!
>=20
> Regards,
> Bernd.


How does everyone feel about using a wiki?  Take a look at this:=20
http://psplinux.sourceforge.net/ -- These folks are using MediaWiki,
the software behind the WikiPedia project, on their Source Forge
hosted web site.

Now take a look at this site:  http://hula-project.org -- This is the
exact same software with a different template running the main website
for Novell's new Hula mail/calendar server software.  Looks nice.

I've looked at MediaWiki briefly.  It comes with half a dozen
templates which can be used as a starting point to achieve the look
and feel that Bernd's developed.

I think we'd run it slightly differently than the AOLserver wiki we're
already familiar with.  We'd auto-generate Zoran's fancy new docs from
CVS as static pages, maybe using the wiki for comments.  Also, we'd
auto-generate a list of modules straight out of CVS so that it's
always up-to-date.

So, how about it?  I think it would be an easy, low maintenance way to
get a lot of people participating quickly.

Re: [naviserver-devel] Move nscgi to modules?

[Bernd E. <eid...@we...>]

> How about nsdb?  This is an important module for people, but I'm
> hoping my newer nsdbi will be a big enough improvement that it becomes
> the new standard.  In that case, it's kind of confusing to ship the
> old version.  Maybe it's something for the future.  What do folks
> think?

In what ways will it be different (i'm curious :-)) ? 

If the existing drivers (and api) still work with nsdbi, I would vote for 
using it and moving nsdb to the modules. So people can still use nsdb if they 
need to.

As with nscgi I would vote for leaving it as some useful software still needs 
CGI.

Bernd.