LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
June Genis <GA.JRG@STANFORD>
Fri, 3 Jun 88 13:37:03 PDT
text/plain (42 lines)
REPLY TO 06/03/88 12:43 FROM [log in to unmask] "Revised LISTSERV forum":
User Directory Service
 
>          The big drawback with the seperate server solution was that
>it was going to require much more software development than would
>adding to Eric's code, which seems to be written in such a manner that
>expanding its functionality is a relatively simple matter.
 
My thought was that you might be able to pirate most of the code
over to the new server but chop out the code for other functions
while adding the multi session support.  Of course, since I'm not a
VMer I've never actually poked around in Eric's code so this might
be a lot harder than I think it would be.
 
>Of course, perhaps user directory services don't belong in LISTSERV.
>But since we wanted something quick and easy to develop, LISTSERV seemed
>the naural place to put it.
 
Better in LISTSERV than nowhere, but I'm inclined to believe that
directory services are a big enough and important enough area that
a separate facility, at least from the user's perspective, is in
order.  While being able to search LISTSERV notebooks with the
LISTSERV database facility is easy to understand, I'm not sure that
LISTSERV as a general data base tool for other files isn't a little
confusing too.  Maybe all that's really needed are some simple
servers with more meaningful names that just pass off to and use the
code from LISTSERV as appropriate.  In general I've found that the
more any product tries to cover the world (we call it
Sherwin-Williams syndrome around here but I guess that's a US only
joke :-), the more difficult it becomes to navigate within it.  I
fear that LISTSERV may be reaching the limit for a manageable scope
of function, especially given that the documentation seems to be
slipping farther behind the product all of the time [but that could
be the subject of anothe whole discussion in itself]
 
>-Chuck
> Systems, NCSU Computing Center
 
/June
 
To:  [log in to unmask]

ATOM RSS1 RSS2