Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!pur-ee!youngb
From: youngb@pur-ee.UUCP (H. Bret Young)
Newsgroups: comp.sys.amiga.tech
Subject: Re: File Requesters
Message-ID: <11577@pur-ee.UUCP>
Date: 5 May 89 22:50:27 GMT
References: <6342@ardent.UUCP>
Distribution: na
Organization: Purdue University Engineering Computer Network
Lines: 69

From article <6342@ardent.UUCP>, by rap@rap.ardent.com (Rob Peck):
-> Perry's posting about file requesters made me think just a little bit
-> about my own preferences on file requesters.
-> 
-       [stuff deleted]
-> 
-> Third wish - cacheing of the file directory contents on a per-task
-> basis, so that it is not necessary to seek all over creation to
-> build the file list for the requester.  Especially if there are
-> 120 file and so on in a single directory (strange practice, but
-> it happens).  Suggest that each task pass a pointer to a data
-> structure of some kind similar to this:
-> 
-> 	#define NEWFILEDIR 0
-> 	#define SEARCHFILE 1
-> 	#define ENDFILEDIR 2
-> 
-> 	struct FileDir {
-> 		char *dir;	/* pointer to full pathname */
-> 		char *dirlist;  /* pointer to first character of
-> 				 * a string of filenames,
-> 				 * each name a null-terminated string*/
-> 		char *chosen;	/* pointer to the filename that was chosen
-> 				 * or to a string that describes a directory
-> 				 * for which a list is to be built */
-> 		int pathsize;	/* size of the pathname string */
-> 				/* (REDUNDANT, available from strlen) */
-> 		int listsize;	/* size of the filename list */
-> 		int chosensize; /* size of the chosen filename */
-> 				/* (REDUNDANT, available from strlen) */
-> 		int action;	/* what to do this time */
-> 		int sliderpos;  /* where did I leave the slider? */
-> 		struct DateStamp ds; /* when did we build this list */
-> 	};
-> 
-> User allocates one of these data structures for EACH directory
-> he wishes to cache.  Then sends the address of this data structure
-> to the file requester.
-> 
-> (BEGIN PSEUDOCODE)
->
-      [code deleted]
-> 
-> (END PSEUDOCODE)
-> 
-> The reason I propose something like this is then a program can
-> maintain as many "cached" directories as it wishes, and pass to the
-> file requester the pointer to the one it wants to choose from.
-> 
-> The above proposal may, of course, be incomplete, but I hope it
-> gives the re-entrant file requester writers something to think about.
-> 
-> And, for that matter, perhaps this pointer can be part of an AREXX
-> message so that we get the benefit of AREXX compatibility at the
-> same time.
-> 
-> Rob Peck			...uunet!ardent!rap

You know ... I was just thinking today that I wish I had file completion
in my ARP shell. I was trying to figure out a nice way to do this (i.e. fast)
when I read the above posting. Unless I am missing something, wouldn't the 
above method of cacheing file directories to get faster and better file
requestors also give as an immediate side effect the ability to implement
file completion with almost no extra cost. I like it. What do you think?

				Bret

ARPA:    youngb@eg.ecn.purdue.edu
UUCP:    youngb@pur-ee.uucp