From: Zoran V. <zv...@ar...> - 2005-06-10 08:07:19
|
Hi! In the process of wholesale cleanup, we might consider moving the nscgi module out of the main server and into the modules section. The nslog/nsperm/nscp are pretty important to the server operation and I'd leave them where they are. Just the nscgi thing: we never needed it. Not something of the terrible importance. Just a thought. Cheers Zoran |
From: Stephen D. <sd...@gm...> - 2005-06-13 07:17:56
|
On 6/10/05, Zoran Vasiljevic <zv...@ar...> wrote: > Hi! >=20 > In the process of wholesale cleanup, we might consider > moving the nscgi module out of the main server and > into the modules section. >=20 > The nslog/nsperm/nscp are pretty important to the server > operation and I'd leave them where they are. Just the > nscgi thing: we never needed it. >=20 > Not something of the terrible importance. Just a thought. Hmm, not sure. It's a universal standard for web servers, I think people expect it. 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? |
From: Bernd E. <eid...@we...> - 2005-06-13 07:49:13
|
> 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. |
From: Stephen D. <sd...@gm...> - 2005-06-13 08:08:11
|
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. |
From: Zoran V. <zv...@ar...> - 2005-06-13 08:16:46
|
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 |
From: Vlad S. <vl...@cr...> - 2005-06-13 14:53:22
|
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/ |
From: Stephen D. <sd...@gm...> - 2005-06-14 07:36:13
|
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. |