lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV Re: External command


From: Wayne Buttles
Subject: Re: LYNX-DEV Re: External command
Date: Sat, 19 Apr 1997 14:26:38 -0400 (EDT)


On Sat, 19 Apr 1997, Al Gilman wrote:

>   X-URL: http://www.flora.org/lynx-dev/html/month0497/msg00670.html
>   
>   This would allow for background downloads.  As I said in the beginning,
>   since we can't actually take control of an already open connection (at
>   least, I can't), we can't do this for files that are the result of a form.
> 
> [Al, here...]  
> 
> Can anyone else help with the "capturing the current activity
> stream" issue?  In terms of process control, one often discovers
> that a fetch is tedious after it is in process.  It would be nice
> to be able to do an after-the-fact "Push the ongoing fetch into a
> background thread and let me forge ahead, please."

AFAIK, this would either require lynx to spawn off parts of itself or for
helper apps to be written specifically for lynx.  I am not interested in
this project for reasons explained further down.

> In the case of slow fetches, the user would like to know when it
> is done and may well wish to visit the resource with Lynx once it
> is local.

None of the GUI browsers can even do this.  I am not saying lynx shouldn't
be better than them, just that I don't know of another app that does.

> I agree with one of the earlier commentors that one operation per
> type is insufficient, in general.  This should work more like the
> tag-and-operate in DIRED.

I agree with you in some situations.  For me it will be a nucience to have
to select the one method I want to use every time.  I think this can be
built on later after I see single methods working.

> This is ambitious.  But it gives some idea of how this fits in
> with other things Lynx already does and other things that people
> want (like re-fetch through filter).

Yes, people want it but I don't think it goes along with what lynx already
does from a technical standpoint.  I would say that it goes more in line
with how we want lynx to *be*  If/when lynx was composed of more contained
objects we could fire them off at will as well as modify their behavior
for things like tables/sub-tables or real frames.  At least that is how I
see it.  Then again, I am not an expert at spawning child processes.
Maybe the people who did the work with forked lookups (which I haven't
used) can comment on the feasability of your features.

Wayne

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]