Menu
▾
▴
naviserver-devel
|
From: Vasiljevic Z. <zv...@ar...> - 2008-05-07 15:05:33
|
Hi! I believe we talked about that some time ago already. Does anybody have any interest in making us being a yet-another Tcl loadable extension? One that you could for example "package require naviserver" and then configure and start/manage several virtual http servers from within a Tcl environment/program? Here I do not think about loading the libnsd.so only. I mean the complete server plus modules. Cheers Zoran |
|
From: Vlad S. <vl...@cr...> - 2008-05-07 17:15:34
|
Once you started the server, it is not Tcl package anymore, need nscp to access it. Or i am not following? Vasiljevic Zoran wrote: > Hi! > > I believe we talked about that some time ago already. > Does anybody have any interest in making us being a > yet-another Tcl loadable extension? One that you could > for example "package require naviserver" and then > configure and start/manage several virtual http servers > from within a Tcl environment/program? > > Here I do not think about loading the libnsd.so only. > I mean the complete server plus modules. > > Cheers > Zoran > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Vasiljevic Z. <zv...@ar...> - 2008-05-07 19:00:47
|
On 07.05.2008, at 19:15, Vlad Seryakov wrote: > Once you started the server, it is not Tcl package anymore, need > nscp to > access it. Depends. If you think in the box, yes. If you step out of the box then yes and no. What I actually think is to marry the rw-config module with the code and make the server configuration from Tcl. Say, each new virtual server gets its own Tcl command that can be used to modify the config on the fly etc.pp. The whole idea is still in a very very rudimentary state. What I would like to achieve is really to get more people evaluate the server by simply snap-in the package and fire-up one or more virtual servers. All under exteral (Tcl) control. This would mean some considerable re-plumbing in ns_main.c but it ls doable. Allright, perhaps some more plumbing... Zoran |
|
From: Stephen D. <sd...@gm...> - 2008-05-23 21:21:04
|
On Wed, May 7, 2008 at 7:59 PM, Vasiljevic Zoran <zv...@ar...> wrote: > > On 07.05.2008, at 19:15, Vlad Seryakov wrote: > >> Once you started the server, it is not Tcl package anymore, need >> nscp to >> access it. > > > Depends. If you think in the box, yes. If you step out > of the box then yes and no. > > What I actually think is to marry the rw-config module > with the code and make the server configuration from > Tcl. Say, each new virtual server gets its own Tcl > command that can be used to modify the config on the > fly etc.pp. The whole idea is still in a very very > rudimentary state. What I would like to achieve is > really to get more people evaluate the server by > simply snap-in the package and fire-up one or more > virtual servers. All under exteral (Tcl) control. > > This would mean some considerable re-plumbing in > ns_main.c but it ls doable. Allright, perhaps > some more plumbing... > Some kind of ns_daemon command as a module, incorporating all the startup guts such as the forking into the background, session id stuff, changing user/group, chroot, windows service/unix watchdog. That would be a genuinely useful standalone Tcl module, and might actually clean up some of the startup code. So 'nsd' would be a Tcl script which parses the command line, calls ns_daemon -user .. -group .. -chroot .. (or whatever) and then jumps into the main main libnsd binary. The 'daemon' stuff seems to be a logical chunk of functionality. |
|
From: Andrew P. <at...@pi...> - 2008-05-07 20:45:11
|
On Wed, May 07, 2008 at 05:05:13PM +0200, Vasiljevic Zoran wrote: > Does anybody have any interest in making us being a > yet-another Tcl loadable extension? Yes. From his past comments on the AOLserver list, Jeff Hobbs would probably be interested too. -- Andrew Piskorski <at...@pi...> http://www.piskorski.com/ |
|
From: Vlad S. <vl...@cr...> - 2008-05-07 20:51:28
|
On other hand, as a server with binary modules i can use it completely without Tcl or Web/ADP stuff. As swiss-army server framework it can be very useful without using Tcl, and i actually use it this way in multiple places. Adding Tcl to this just makes it much more flexible and powerful but making binary server as Tcl package and require it to run within Tcl i am not sure i like. Making libnsd.so true Tcl package i would like to help though. Andrew Piskorski wrote: > On Wed, May 07, 2008 at 05:05:13PM +0200, Vasiljevic Zoran wrote: > >> Does anybody have any interest in making us being a >> yet-another Tcl loadable extension? > > Yes. From his past comments on the AOLserver list, Jeff Hobbs would > probably be interested too. > |
|
From: Vasiljevic Z. <zv...@ar...> - 2008-05-08 06:55:04
|
On 07.05.2008, at 22:51, Vlad Seryakov wrote: > Adding Tcl to this just makes it much more flexible and powerful but > making binary server as Tcl package and require it to run within Tcl i > am not sure i like. Well, it is not or-or. It is both. I would not just ditch the standalone version. Instead, I would create a separate wrapper in parallel to ns_main that loads the thing as Tcl extension and maniplates the config from the Tcl side (by means of new per-virtual-server commands or such). > > > Making libnsd.so true Tcl package i would like to help though. Isn't that already done? You can do "load lobnsd.so" in a Tcl shell even today. Zoran |
|
From: Vlad S. <vl...@cr...> - 2008-05-08 14:34:13
|
Vasiljevic Zoran wrote: > On 07.05.2008, at 22:51, Vlad Seryakov wrote: > >> Adding Tcl to this just makes it much more flexible and powerful but >> making binary server as Tcl package and require it to run within Tcl i >> am not sure i like. > > Well, it is not or-or. It is both. I would not just ditch the > standalone version. Instead, I would create a separate wrapper > in parallel to ns_main that loads the thing as Tcl extension > and maniplates the config from the Tcl side (by means of new > per-virtual-server commands or such). Ok, i agree >> >> Making libnsd.so true Tcl package i would like to help though. > > Isn't that already done? > You can do "load lobnsd.so" in a Tcl shell even today. I know but i heard that it is not complete and some part does not work or something like that, i will not speculate on this... I guess if libnsd.so would be true complete Tcl package we would not be discussing this :-))) |
|
From: Jeff R. <dv...@di...> - 2008-05-07 21:00:59
|
Andrew Piskorski wrote:
> On Wed, May 07, 2008 at 05:05:13PM +0200, Vasiljevic Zoran wrote:
>
>> Does anybody have any interest in making us being a
>> yet-another Tcl loadable extension?
>
> Yes. From his past comments on the AOLserver list, Jeff Hobbs would
> probably be interested too.
Rather than the entire server being a loadable extension, what about
breaking out the major c-coded functional pieces into a group of
loadable extensions? The modules could include adp (a fast/extensible
template engine), urlspace (a trie oriented around urls), driver (a
threaded alternate to the standard tcl event loop, oriented around
creating events on one thread to be dispatched on others), and of
course, db for database access. Some other pieces of functionality,
like scheduled jobs ("after") , ns_sets (dicts?), nsv shared variables
(thread package tsvs), http, and sockets seem to be already sufficiently
covered in the core or standard tcl library.
-J
|
|
From: Vasiljevic Z. <zv...@ar...> - 2008-05-08 06:52:00
|
On 07.05.2008, at 23:00, Jeff Rogers wrote:
> Andrew Piskorski wrote:
>> On Wed, May 07, 2008 at 05:05:13PM +0200, Vasiljevic Zoran wrote:
>>
>>> Does anybody have any interest in making us being a
>>> yet-another Tcl loadable extension?
>>
>> Yes. From his past comments on the AOLserver list, Jeff Hobbs would
>> probably be interested too.
>
> Rather than the entire server being a loadable extension, what about
> breaking out the major c-coded functional pieces into a group of
> loadable extensions? The modules could include adp (a fast/extensible
> template engine), urlspace (a trie oriented around urls), driver (a
> threaded alternate to the standard tcl event loop, oriented around
> creating events on one thread to be dispatched on others), and of
> course, db for database access. Some other pieces of functionality,
> like scheduled jobs ("after") , ns_sets (dicts?), nsv shared variables
> (thread package tsvs), http, and sockets seem to be already
> sufficiently
> covered in the core or standard tcl library.
Interesting idea. This would definitely add more tools to Tcl
programmer.
But I was not targeting this. I was targeting people that might needing
a web-service in their programs. So w/o much fuss, load the extension
and
start using (web-server) immediately. Splitting the server in parts and
then glueing all together would be considerable more effort then
wrapping
the server as-is in a Tcl extension. But, generally speaking, on the
mid/long
run we could consider taking the server piece-by-piece apart and
making it
more modular then it is now, this is true.
Cheers
Zoran
|
|
From: Stephen D. <sd...@gm...> - 2008-05-23 21:24:18
|
On Wed, May 7, 2008 at 10:00 PM, Jeff Rogers <dv...@di...> wrote: > Andrew Piskorski wrote: >> On Wed, May 07, 2008 at 05:05:13PM +0200, Vasiljevic Zoran wrote: >> >>> Does anybody have any interest in making us being a >>> yet-another Tcl loadable extension? >> >> Yes. From his past comments on the AOLserver list, Jeff Hobbs would >> probably be interested too. > > Rather than the entire server being a loadable extension, what about > breaking out the major c-coded functional pieces into a group of > loadable extensions? The modules could include adp (a fast/extensible > template engine), urlspace (a trie oriented around urls), driver (a > threaded alternate to the standard tcl event loop, oriented around > creating events on one thread to be dispatched on others), and of > course, db for database access. It wouldn't be too hard to enable nsdbi as a Tcl package. It can already change config settings at runtime. It just needs to be taught to use those commands to load it's initial config when first loaded, and a couple of other bits and pieces. |
|
From: Andrew P. <at...@pi...> - 2008-05-07 21:17:25
|
On Wed, May 07, 2008 at 04:51:27PM -0400, Vlad Seryakov wrote: > On other hand, as a server with binary modules i can use it completely > without Tcl or Web/ADP stuff. AFAIK, it is impossible to run either AOLserver or Naviserver without at least one Tcl interpreter loaded in there somewhere. It is also impossible to compile it without linking against Tcl. -- Andrew Piskorski <at...@pi...> http://www.piskorski.com/ |
|
From: Vasiljevic Z. <zv...@ar...> - 2008-05-08 06:44:52
|
On 07.05.2008, at 23:17, Andrew Piskorski wrote: > AFAIK, it is impossible to run either AOLserver or Naviserver without > at least one Tcl interpreter loaded in there somewhere. It is also > impossible to compile it without linking against Tcl. > I think what Vlad wanted to say is that he needs no Tcl scripting taking place (all can be done in loaded C-modules). Of course, the server is heavily dependent on Tcl library but not directly on executing Tcl scripts. Cheers Zoran |
×
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