Nick: I think the "Subject:" field is accepted on IBM notes provided it
appears AFTER all the mandatory tags. You can also use "Subj:".
Jeff: you're right, but this implies an additional call to LSVKEYWD and 5
more lines of code whenever I need to look at the Notebook tag, which is why I
used a hardcoded default from the beginning. I'm not too keen on changing this
one -- just make the notebook public in the mail header. I'd do it if
everybody really thinks that it's really important.
Notebooks: well, several things are sure...
1) It is IMPOSSIBLE to keep a list of all subscribers to a given list. I had
contemplated doing it in the past to solve the problem with people
attempting to mail to a 'foreign' peer when theirs was down and Send=
Private, or people wanting to REV (LOC a list at some peer where Review=
Private, etc. I was completely discouraged by the number of people who
modify their LIST files using XEDIT from the LISTSERV machine, thwarting
any attempts at synchronizing the recipients lists.
2) Item (1) implies that someone who's registered at a server which doesn't
keep notebooks will not be able to get them by asking another server
directly. We're speaking of the Notebook= Yes,Private case only, of course.
3) A server which doesn't keep notebook could be caused to automatically
forward the request to other peers (in much the same way as a REVIEW
command gets forwarded). This would unavoidably cause multiple notebooks to
be sent to the originator... unless there is a keyword telling the server
which peers are presently keeping notebooks. The following syntax might
work:
- Extend the first operand of the Notebook= field: Yes | No | Peers. All
the other operands still apply.
- Add a new keyword: Archivers= node1,node2,<user3@>node3... Same format
as the Peers= keyword but it lists those peers who're keeping notebooks
- Notebook= Peers,... means that if 'my node' appears in Archivers, I
keep a notebook, else I don't (this allows the list header to be the
same for all nodes; a variation might be Peers --> I don't keep one).
If I don't keep a notebook, I'll forward to the nearest (LSVBITFD-wise)
server.
4) Problem: you need to know the fileid of the notebook file you want. That
means you must be able to GET listname FILELIST. If it's GET = ALL, no
problem; however, there are cases where you'd want it to be GET = PRV, for
example if you have Notebook= Yes,Private,..,Separate and you feel that
some of the Subject: tags (they appear in the filelist in that case) are
confidential. In that case the guy won't be able to get the filelist.
Besides, the fileid may not be the same for all the servers in case logging
is set to Separate, and you may not know in advance which server you'll get
your notebooks from. So we need the same kind of auto-forwarding facility
on 'listname FILELIST' (I intend to drop the NOTEBOOK FILELIST soon, it
costs too much CPU time to build and is really too large; to com- pensate,
LISTSERV will automatically build a default 'listname FILELIST' if none
exists on the A-disk -- GET code will be PRV).
Does that sound ok to all of you?
Two other problems:
1) Due to some old areas of code in LSVDIST EXEC (dating back from the time
that ALL servers were automatically part of the DISTRIBUTE backbone),
version 1.5h of LISTSERV crashes with a REXX error whenever a global PUT
command (such as my PUT PEERS NAMES) is distributed to a server which has
disabled the DISTRIBUTE function. I'll fix that, but I wanted to warn you
about the problem. Affected servers are those who're next to a server which
has disabled DISTRIBUTE.
2) Due to the limit that CMS places on the number of arguments you may pass to
a program, all servers will crash with REXX errors as soon as the 60th
LISTSERV is added to PEERS NAMES... :-( The various options, eg (STACK,
will be moved to the left and programs like LSVBITFD will successfully
complete with data being typed on the terminal, not stacked. When LISTSERV
issues a PULL command it will be in big troubles. I'll make sure to find a
solution BEFORE letting more than 59 servers in PEERS NAMES :-)
3) Due to internal coding conventions, servers with DISTRIBUTE disabled are
unable to process multiple-hosts PUT commands such as PUT PEERS NAMES. The
problem is easy to understand: DISTRIBUTE is used to propagate the file to
be stored through the network. Whenever the destination for a file is a
list server, it is a convention that what the sender wanted the server to
do is to process the file as if it had been sent directly to the server's
reader. For obvious security validation reasons, the DISTRIBUTE job is then
forwarded (instead of being distributed) to the target LISTSERV, ie it does
not get the file from another server but a DISTRIBUTE job with only one
recipient: itself. Servers with DISTRIBUTE disabled will zap the job before
even looking into it. This is a tough problem, but I'll try to find a way
out. Just don't be surprised if it happens.
Eric
|
