Eric, Thanks for the update regarding the questions I posed. Let me
comment.
 
>Date:         Wed, 27 Mar 1996 23:00:34 +0100
>From: Eric Thomas <[log in to unmask]>
 
> This
>includes the ability to create catalogs (similar to the VM FILELISTs) and
 
Good.
 
>to organize files in  a hierarchical manner, so that you  can have a file
>called  /abc/def/ghi/my.file,
 
Good. No explicit mention of Packages. Since a file might belong to
several Packages, I'm not ready to equate Package to directory contents.
But, rather than speculate on how an owner could "work around" a formal
lack of Packages, perhaps by ingenious use of Unix links, I'll just ask
you --what's the plan for Packages?
 
>although  during  phase 1  this  will  not
>necessarily be  very user friendly  for the person maintaining  the files
>and directories.
 
I don't care --that's an ok priority.
 
>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).
 
Again, I'd like to read into this statement that Packages are one of the
"file server" functions, but I'll let you tell me.
 
>Phase 2  will contain  further improvements  that
>will, to  a large  extent, be  based on  customer feedback  following the
>release of  phase 1.
 
OK.
 
>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.
 
I'm not sure what this means. Web-based menus/point and click/reply to
prompts/links is great stuff, but it's not database stuff. Much of what a
discussion list is --is text.  So, the graphical stuff you refer to
must mean the interface and not graphical information content.
 
Now, if you look around at web-based search engines, lots of the
default, cheap-o ones don't hold a candle to the depth of your
VM Search command (unless they are based on significant, tailored,
database backend engines with a full query language [many of which are
oriented towards the relational model of data representation, and are
often weak on complex text searches).
 
Frankly, I'd rather have the early use of your Search command than
a fancy user interface that returns results to limited-capability
boolean queries. Getting finely tuned hits on large text bases, consisting
of units called messages, ought to have a high priority, regardless
of user-friendliness achievements. If you can provide this text-rich
Search functionality in a nice user interface, fine. But, for my
money, I put a premium on the power of the search engine. Now, I
suppose you could provide a PERL-like regular expression alternative to
your VM Search command, but that probably wouldn't be a hot sale item  ;>)
 
>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
 
Again, let's separate out user interface from search engine capabilities
as we discuss priorities.
 
> The file server functions got done
>first because there  were a lot more people asking  for them, and because
>they aren't controversial.
 
Fine by me, as long as they come sooner than later*. You created a monster,
Eric. Now, the hungry masses want to see it reproduce in all corners
of the globe, for their amusement....
 
>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
 
Absolute must! No entire LOG files, please.
 
>...  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?
 
See my comments above. The "simpler" syntax you imply wouldn't buy much
more than echoing messages to a web/hypermail server and letting
people do their searching, such as it is, there (which is what some
lists have been doing, as I mentioned earlier).
 
>Finally, the main reason we're late for all these developments is that we
>don't have enough manpower.
 
Success is Hell....
 
>  Eric
 
Thanks again,
Peter
 
* "Sooner" is well before the end of _this_ year; later is not.