Menu
▾
▴
naviserver-devel
|
From: Vlad S. <vl...@cr...> - 2005-03-06 23:17:47
|
Hi guys, Do you have any roadmap-kind of plans or thoughts about naviserver? Slowly it is getting to the point when it can replace all my patched aolservers, i already use it at home instead of AS. As i remember, the initial goal was to patch AS with all out modifications so we start using it instead of AS and then decide what to do next, right? So, 1. Do you have any thoughts about Web tools/frameworks we can bundle with it? 2. Which modules should be in the distrib? 3. Docs are still needed to be addressed, when i do not have strength to develop late evenings i could write/add docs but which format we gonna use? 4. Do we need to refine installation procedure? After installation, going to port 8080 (this way no need root to install and test it) the user should see some kind of web page with at least stats and docs (similar to apache, that is the big hole in AS right now) -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2005-03-07 08:21:45
|
On Monday 07 March 2005 00:17, Vlad Seryakov wrote: > Hi guys, > > Do you have any roadmap-kind of plans or thoughts about naviserver? I don't, yet. My primary goal is to get to a point where we can switch to naviserver internally. I'm still not there, so for me there is more work to do. > Slowly it is getting to the point when it can replace all my patched > aolservers, i already use it at home instead of AS. As i remember, the > initial goal was to patch AS with all out modifications so we start > using it instead of AS and then decide what to do next, right? > > So, > > > 1. Do you have any thoughts about Web tools/frameworks we can bundle > with it? I have no idea. We are using the server with our own templating framework based on tDOM but I do not think this is something of general interest. > 2. Which modules should be in the distrib? We use only our own modules. But, generally speaking, a couple of database drivers should be there (postgres, ... ?) > 3. Docs are still needed to be addressed, when i do not have strength to > develop late evenings i could write/add docs but which format we gonna use? I'm already working on this. I'd opt to use Tcl doctools. It allows to write good Tcl/C docs in a very simple POD-like format and it produces nroff, html and wiki output (among others). In some weeks I will have a complete set of everything needed to start filling in content. There is already content on AOL site and some on the wiki. It should be easy to cut/paste from there after the frwamework has been setup. > 4. Do we need to refine installation procedure? > After installation, going to port 8080 (this way no need root to install > and test it) the user should see some kind of web page with at least > stats and docs (similar to apache, that is the big hole in AS right now) This is OK. > > > -- > Vlad Seryakov > 571 262-8608 office > vl...@cr... > http://www.crystalballinc.com/vlad/ > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- With kind regards, Mit besten Gruessen, Meilleures Salutations, ___________________________________________ Zoran Vasiljevic, Vice President, CTO E-mail: mailto:zv...@ar... Web: http://www.archiware.com Phone: +49 89 319 084 98 Fax: +49 89 319 084 99 S-mail: ArchiWare(R) GmbH Gutenbergstr. 3 D-85716 Munich, Germany ___________________________________________ PresSTORE(R) - Backup Synchronize Archive |
|
From: Vlad S. <vl...@cr...> - 2005-03-07 14:58:18
|
> > I don't, yet. My primary goal is to get to a point where we can > switch to naviserver internally. I'm still not there, so for me > there is more work to do. Can you tell what do you still need? > I have no idea. We are using the server with our own templating > framework based on tDOM but I do not think this is something > of general interest. I have light-weight templating i can extract and put into modules/tcl, that will be one small file and will support OACS-style templating where .adp and .tcl are define template. But it requires some work to be extracted from my "big" framework system. >>2. Which modules should be in the distrib? > > > We use only our own modules. But, generally speaking, a couple > of database drivers should be there (postgres, ... ?) For public version in the future i would include as manu maintained modules as possible. -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2005-03-07 08:33:10
|
In nslog.c:
/* Get parameters from configuration file */
logPtr->rollfmt = Ns_ConfigGetValue(path,"rollfmt");
if (logPtr->rollfmt == NULL) {
logPtr->rollfmt = ns_strdup(logPtr->rollfmt);
}
This is not what the writer wanted, or?
I assume it should have been written as:
/* Get parameters from configuration file */
logPtr->rollfmt = Ns_ConfigGetValue(path,"rollfmt");
if (logPtr->rollfmt != NULL) {
logPtr->rollfmt = ns_strdup(logPtr->rollfmt);
}
I will fix this in head.
Zoran
|
|
From: Vlad S. <vl...@cr...> - 2005-03-07 14:36:39
|
Ouch, my bad
Zoran Vasiljevic wrote:
> In nslog.c:
>
> /* Get parameters from configuration file */
> logPtr->rollfmt = Ns_ConfigGetValue(path,"rollfmt");
> if (logPtr->rollfmt == NULL) {
> logPtr->rollfmt = ns_strdup(logPtr->rollfmt);
> }
>
> This is not what the writer wanted, or?
> I assume it should have been written as:
>
> /* Get parameters from configuration file */
> logPtr->rollfmt = Ns_ConfigGetValue(path,"rollfmt");
> if (logPtr->rollfmt != NULL) {
> logPtr->rollfmt = ns_strdup(logPtr->rollfmt);
> }
>
> I will fix this in head.
>
> Zoran
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> 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: Bernd E. <eid...@we...> - 2005-03-07 15:30:16
|
Hi Vlad, > > I have no idea. We are using the server with our own templating > > framework based on tDOM but I do not think this is something > > of general interest. > > I have light-weight templating i can extract and put into modules/tcl, > that will be one small file and will support OACS-style templating > where .adp and .tcl are define template. But it requires some work to be > extracted > from my "big" framework system. I would also like to extract some functionality from our toolkit. It would be nice if there is a small toolkit with basic stuff like database abstraction, page and session management, authentication and basic permissions. I like the idea to rewrite it in a way so that it utilizes new naviserver functions like the c-cookie-api or database stuff (I read from Stephen?). In our framework we do not map and use the standard ADP-stuff, we use registered filters and procs and ns_adp_parse files, but it should be managable to rewrite it. > For public version in the future i would include as manu maintained > modules as possible. What do you think about a "contrib" directory (like in PostgreSQL or other packages): <QUOTE> The PostgreSQL contrib tree --------------------------- This subtree contains porting tools, analysis utilities, and plug-in features that are not part of the core PostgreSQL system, mainly because they address a limited audience or are too experimental to be part of the main source tree. This does not preclude their usefulness. Each subdirectory contains a README file with information about the module. </QUOTE> Something similar. This way it would be clearly stated that something is useful and/or experimental and/or just new (Message: "Give it a try"). Maybe this would be a place for a chroot-installation-script, like my first try here: http://www.kinetiqa.de/aolserver/ (But rewritten, it's a little bit old and worries about too many packages) Bernd. |
|
From: Vlad S. <vl...@cr...> - 2005-03-07 15:36:57
|
Yes, contrib directory is a good idea Bernd Eidenschink wrote: > Hi Vlad, > > >>>I have no idea. We are using the server with our own templating >>>framework based on tDOM but I do not think this is something >>>of general interest. >> >>I have light-weight templating i can extract and put into modules/tcl, >>that will be one small file and will support OACS-style templating >>where .adp and .tcl are define template. But it requires some work to be >>extracted >>from my "big" framework system. > > > I would also like to extract some functionality from our toolkit. It would be > nice if there is a small toolkit with basic stuff like database abstraction, > page and session management, authentication and basic permissions. > I like the idea to rewrite it in a way so that it utilizes new naviserver > functions like the c-cookie-api or database stuff (I read from Stephen?). > In our framework we do not map and use the standard ADP-stuff, we use > registered filters and procs and ns_adp_parse files, but it should be > managable to rewrite it. > > >>For public version in the future i would include as manu maintained >>modules as possible. > > > What do you think about a "contrib" directory (like in PostgreSQL or other > packages): > > <QUOTE> > > The PostgreSQL contrib tree > --------------------------- > This subtree contains porting tools, analysis utilities, and plug-in > features that are not part of the core PostgreSQL system, mainly because > they address a limited audience or are too experimental to be part of > the main source tree. This does not preclude their usefulness. > > Each subdirectory contains a README file with information about the > module. > > </QUOTE> > > Something similar. This way it would be clearly stated that something is > useful and/or experimental and/or just new (Message: "Give it a try"). > > Maybe this would be a place for a chroot-installation-script, like my first > try here: > http://www.kinetiqa.de/aolserver/ > (But rewritten, it's a little bit old and worries about too many packages) > > Bernd. > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > 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-03-08 06:17:35
|
Sounds like a packaging problem to me. Bundling modules into the core will only turn it into a development/release problem. Large projects actually seem to be going the other way: Postgres are moving things out of core and onto gborg; X.org is busy splitting up into server, fonts, utils, etc. What about the many modules and features that don't make it into core, do we just acknowledge that they will be a complete pain to build and install? I'm so lazy that I package all my software into RPMs. I only have to do it once, and from then on it's a doddle to install consistently on multiple machines without referring to docs or making mistakes. If y'all are dead set against whatever packaging system is native to your OS, you still have options. The Gnome and KDE projects for example have created build scripts which automatically download the source from cvs, build, and install, managing dependencies and build order. Can we put all non-core modules in a 'modules' directory in cvs? I thought it would be cool if each one had some meta data associated with it, maybe use something like the DOAP format: http://usefulinc.com/doap There would be a little script which automatically builds web pages for all modules each night. Packages would be auto-built and placed int yum/apt repositories. There would be links to CVS, the bug tracker for that module, the latest entries in the ChangeLog... That's my grand vision for modules and packaging -- a small shell script will replace me! How does this sound? What OS are you installing on? On Mon, 7 Mar 2005 16:34:55 +0100, Bernd Eidenschink <eid...@we...> wrote: > Hi Vlad, > > > > I have no idea. We are using the server with our own templating > > > framework based on tDOM but I do not think this is something > > > of general interest. > > > > I have light-weight templating i can extract and put into modules/tcl, > > that will be one small file and will support OACS-style templating > > where .adp and .tcl are define template. But it requires some work to be > > extracted > > from my "big" framework system. > > I would also like to extract some functionality from our toolkit. It would be > nice if there is a small toolkit with basic stuff like database abstraction, > page and session management, authentication and basic permissions. > I like the idea to rewrite it in a way so that it utilizes new naviserver > functions like the c-cookie-api or database stuff (I read from Stephen?). > In our framework we do not map and use the standard ADP-stuff, we use > registered filters and procs and ns_adp_parse files, but it should be > managable to rewrite it. > > > For public version in the future i would include as manu maintained > > modules as possible. > > What do you think about a "contrib" directory (like in PostgreSQL or other > packages): > > <QUOTE> > > The PostgreSQL contrib tree > --------------------------- > This subtree contains porting tools, analysis utilities, and plug-in > features that are not part of the core PostgreSQL system, mainly because > they address a limited audience or are too experimental to be part of > the main source tree. This does not preclude their usefulness. > > Each subdirectory contains a README file with information about the > module. > > </QUOTE> > > Something similar. This way it would be clearly stated that something is > useful and/or experimental and/or just new (Message: "Give it a try"). > > Maybe this would be a place for a chroot-installation-script, like my first > try here: > http://www.kinetiqa.de/aolserver/ > (But rewritten, it's a little bit old and worries about too many packages) > > Bernd. |
|
From: Zoran V. <zv...@ar...> - 2005-03-07 16:19:25
|
On Monday 07 March 2005 15:55, Vlad Seryakov wrote:
>
> >
> > I don't, yet. My primary goal is to get to a point where we can
> > switch to naviserver internally. I'm still not there, so for me
> > there is more work to do.
>
> Can you tell what do you still need?
On the top of my head:
o. binder listening on all interfaces
o. watchdog process
o. maybe a couple of tiny things which I have yet to find out
when I switch (still didn't switch but this is another story)
Zoran
|
|
From: Vlad S. <vl...@cr...> - 2005-03-07 16:22:47
|
- using -b 0.0.0.0 will listen on all interfaces - watchdog has green light for commit - there are always other tiny things :-))) Zoran Vasiljevic wrote: > On Monday 07 March 2005 15:55, Vlad Seryakov wrote: > >>>I don't, yet. My primary goal is to get to a point where we can >>>switch to naviserver internally. I'm still not there, so for me >>>there is more work to do. >> >>Can you tell what do you still need? > > > On the top of my head: > > o. binder listening on all interfaces > o. watchdog process > o. maybe a couple of tiny things which I have yet to find out > when I switch (still didn't switch but this is another story) > > Zoran > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > 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: Zoran V. <zv...@ar...> - 2005-03-07 16:29:48
|
On Monday 07 March 2005 17:19, Vlad Seryakov wrote: > - using -b 0.0.0.0 will listen on all interfaces I'm afraid this is still not clear to me, but I'll have to give you some examples why this is making me trouble. I will prepare the switch to naviserver in our development branch in couple of days and then this will be clear > - watchdog has green light for commit I would like to see what Stephen thinks about this as well. He wanted some code to look at and I've made the patch available on SF. Hopefully he will have some time to review it and tell what he thinks. > - there are always other tiny things :-))) Oh yes... this is what I'm afraid of! Therefore, I'd have to make the switch first so I can see what is sill lurking in the modified version of AS I have but forgot to clearly comment... Zoran |
|
From: Vlad S. <vl...@cr...> - 2005-03-07 22:42:14
|
>
>>- using -b 0.0.0.0 will listen on all interfaces
>
>
> I'm afraid this is still not clear to me, but I'll have
> to give you some examples why this is making me trouble.
> I will prepare the switch to naviserver in our development
> branch in couple of days and then this will be clear
More correct solution:
nsd ... -b 0.0.0.0
and
ns_section "ns/server/${server}/module/nssock"
ns_param address 0.0.0.0
...
--
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/
|
|
From: Stephen D. <sd...@gm...> - 2005-03-08 06:34:49
|
On Sun, 06 Mar 2005 18:17:06 -0500, Vlad Seryakov <vl...@cr...> wrote: > Hi guys, > > Do you have any roadmap-kind of plans or thoughts about naviserver? > Slowly it is getting to the point when it can replace all my patched > aolservers, i already use it at home instead of AS. As i remember, the > initial goal was to patch AS with all out modifications so we start > using it instead of AS and then decide what to do next, right? > > So, > > 1. Do you have any thoughts about Web tools/frameworks we can bundle > with it? I think it would be very difficult to come up with a standard set of these higher-level features that would please everyone. I'd like to see lot of extra modules in cvs though. > 2. Which modules should be in the distrib? Very few. Less than we have now? Does anybody use that external db stuff? > 3. Docs are still needed to be addressed, when i do not have strength to > develop late evenings i could write/add docs but which format we gonna use? > 4. Do we need to refine installation procedure? > After installation, going to port 8080 (this way no need root to install > and test it) the user should see some kind of web page with at least > stats and docs (similar to apache, that is the big hole in AS right now) I'd like to change the installation layout. Currently it's something like this: /usr/local/ns/ ... bin include lib log man modules sample-config.tcl servers I'd like to drop the enforced 'ns' so that --prefix-... works properly. I'd also like to teach the Makefile to obey the standard configure options like --libdir=... etc. This enables RPM and Deb packages to install things under /usr/lib64 if the machine is an Opteron, for example. Also, placing the 'servers' directory under /usr/local doesn't make much sense. This is root owned so by default you can't edit your own web content. I think the standard place for Linux is now /srv, not sure about the built-in configure default. It also makes sense to me to ship some kind of server deployment script. So rather than install the default servers/server1 and try to grab port 8080, the user would type 'nsdeploy myserver /srv/myserver' or whatever, possible with extra options, and it would create the hierarchy for them. I always end up having multiple installations on one machine. The script could ask questions if you don't supply any args, touch up the config file etc. |
|
From: Vlad S. <vl...@cr...> - 2005-03-08 14:56:46
|
>
> I think it would be very difficult to come up with a standard set of
> these higher-level features that would please everyone. I'd like to
> see lot of extra modules in cvs though.
>
Yes, in CVS, packaging is another issue but having module sin CVS and be
able to download them from one
place is what i mean.
>
> Very few. Less than we have now? Does anybody use that external db stuff?
Currently we have just nssock which is not module anymore per se, just
an attachement to core http driver
for loading more than once instance which is not always clear. May be we
can teach http driver to bind to as many
addresses without loading different modules.
Then nscgi - usefull, nsco - usefull, nsperm - ???, nsext - ???
Not much to have working server, some DB modules should be there, at
least PG, MySQL, SQLite,
thi is the main selling pitch currentlu for AS, native DB support and DB
pooling but none of the DB modules
included.
> I'd like to change the installation layout. Currently it's something like this:
>
> /usr/local/ns/ ...
> bin
> include
> lib
> log
> man
> modules
> sample-config.tcl
> servers
>
Can we move "tcl" from modules/ to the top, ussually modules are
empty directory with tcl entry only, do you use modules/ at all?
Also in my installations i use etc/ for all config files, at least i
have nsd.tcl and mime.tcl(with huge list of all mime types)
there plus some other config specific files. Do you think this is usefull?
Here is my structure ( i am not sugesting it, just show what i use):
/usr/local/ns
bin/
lib/
html/
include/
etc/
logs/
tcl/
--
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/
|
|
From: Bernd E. <eid...@we...> - 2005-03-08 16:14:47
|
> Then nscgi - usefull, nsco - usefull, nsperm - ???, nsext - ??? seems there is a constant interest in nscgi, at least it was talked about a lot of times in the aol-mailinglist. > Not much to have working server, some DB modules should be there, at > least PG, MySQL, SQLite, > thi is the main selling pitch currentlu for AS, native DB support and DB > pooling but none of the DB modules > included. yes, the db modules are important. e.g. openacs community uses postgres and oracle. and maybe smth. for "contrib": there is a sapi/aolserver directory in the PHP-distribution and a patch for that aolserver.c file on the wiki. the original developer seems to be gone (not of the patch, of the file itself). I will try that with 4.3.x and 5.0.x versions of PHP and write a small README about it. |
|
From: Stephen D. <sd...@gm...> - 2005-03-17 12:06:01
|
On Tue, 08 Mar 2005 09:53:21 -0500, Vlad Seryakov <vl...@cr...> wrote: > > /usr/local/ns/ ... > > bin > > include > > lib > > log > > man > > modules > > sample-config.tcl > > servers > > > > Can we move "tcl" from modules/ to the top, ussually modules are > empty directory with tcl entry only, do you use modules/ at all? I didn't realise tcl was in that directory, I was going to suggest moving it in there and renaming it nstcl :-) We have no standard way for people to create Tcl only modules and distribute them as they do binary modules. You often see the instruction "just copy this into your private tcl directory...". I guess we should fix that. My modules directory is full of binary modules. The libnsd.so and libnsdb.so go in the libs directory. A nice Tcl module to ship as standard would be nstelemetry, which is currently a single adp file. With extra hooks into [ns_info filters] etc. it could push back the need for a lot of documentation. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X