Phase 1a of the file server functions has been written and tested. This
includes the ability to create catalogs (similar to the VM FILELISTs) and
to organize files in a hierarchical manner, so that you can have a file
called /abc/def/ghi/my.file, although during phase 1 this will not
necessarily be very user friendly for the person maintaining the files
and directories. Phase 1b is AFD/FUI and a few other minor changes, and
is under development. The plan is to release phase 1 (1a + 1b) together
with version 1.8c. This should, for most sites, provide a similar level
of functionality as the VM file server functions, with a simpler
interface (just like, say, the management of WELCOME files is easier in
the non-VM versions). Phase 2 will contain further improvements that
will, to a large extent, be based on customer feedback following the
release of phase 1. In other words, the design for phase 1 was fairly
straightforward based on what people had been used to since 1987 and on
the code we already had. I expect that people will be able to migrate
from FILELISTs to phase 1 CATALOG files in about 5 minutes, and I don't
expect anyone to have any major complaint, other than "This should be
easier to do, although now that you mention it, it wasn't easy on VM
either". For phase 2 we have all sorts of ideas, but it's not clear what
people will need first.
The database functions are a hot potato because what the majority of our
customers are clamouring for is graphical, web-based database access. We
have reached a point where some customers will actually get very upset if
we release a text-based database engine, unless a web-based database
feature is also provided at the same time. Conversely many long-time VM
customers have indicated that, to a large extent, web-based database
functions would be an acceptable substitute, although there's always a
list or two where this isn't workable. We try to make all customers
happy, but this isn't always possible. The file server functions got done
first because there were a lot more people asking for them, and because
they aren't controversial.
Now, version 1.8c will also include full support for the INDEX
subscription option (already written and tested). This includes a new
command that allows you to retrieve individual messages from the archives
(this command is used internally by the INDEX code, but will be
documented as NDSU's experience with /SHIP makes it clear that this is
something power users do find useful). I imagine that we could implement
a SEARCH command that would look for certain words or phrases in list
archives, and return item numbers that can be used to retrieve the
postings in question. Something similar to SCAN, with a simpler syntax
than the database functions. This might provide some relief for sites
that use the database functions for simple things, and it should
hopefully not alienate the graphical-oriented customers because it is a
minor development that nobody will dream of labeling a "strategic
direction" or anything like that. Comments?
Finally, the main reason we're late for all these developments is that we
don't have enough manpower. We keep hiring people, but we keep not having
enough manpower anyway. We've hired three people in December, one in
February and one this month. Two more are about to be hired,
realistically they'll sign in April. The three we've hired in December
are already overwhelmed, and in a few weeks they're going to have three
new people to train. As the sales folks say, "this is a nice problem to
have", but it's a problem nonetheless. I'm not trying to whine here, but
I'd like to clarify, since it isn't intuitive or obvious, that just
because there are a bunch of qualified list owners out there doesn't mean
that we can hire more support people at the snap of a finger. The list
owners in question have a job as teachers, scientists, journalists, etc.
Most of them simply do not want a career change; they think they're
already spending too much time working on a computer and away from their
field to keep their list together as it is :-) I'll trade you 50 junior
programmer resumes for one seasoned list owner or LISTSERV admin :-)
Eric
|
