lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Wishlist item: semi-persistent session cookies


From: David Combs
Subject: Re: lynx-dev Wishlist item: semi-persistent session cookies
Date: Sat, 2 Mar 2002 19:30:07 -0500
User-agent: Mutt/1.3.25i

On Sat, Feb 16, 2002 at 10:27:51AM -0500, Al Gilman wrote:
...
> 
> The clean model, to satisfy Henry, is that when Lynx is called as a module in 
> a
> larger computation, the session does not end when Lynx exits.  In this case, 
> it
> would seem that the way to handle this is that you pass a handle (filename) to
> where you want the session cookies to be accumulating and the resulting state
> of the session cookie jar is available for the use of the super-process, but
> not something that gets picked up by the next execution of Lynx unless
> explicitly passed back in in the form of a non-empty cookie jar.
> 
> In this case the session cookies live in a customer-process-furnished object
> and not a Lynx-created-and-destroyed temporary object.
> 
> This is callability engineering not beyond what Lynx could absorb.
> 
> Al

What is "callability engineering"?

---
Google finds nothing on "callability engineering",

and about "callability",

99% of what it finds is about bonds!

(except one article on "formal callability":


 Linkname: ICCL 98: Abstract: Formal Callability and its Relevance 
     and Application to Interprocedural Data-flow Analysis
 URL: http://www.computer.org/proceedings/iccl/8454/84540252abs.htm
 
For whatever it might be worth, its Abstract:




  Formal Callability and its Relevance and Application to Interprocedural
  Data-flow Analysis

     Jens Knoop
     Universitaet Passau

     Formal callability is the problem of determining for every formal
     procedure call of a program the set of procedures it may call at
     run-time. This information is the key for constructing the
     procedure call graph of a program, a common prerequisite of static
     analyses of programs with procedures. Moreover, under specific
     side-conditions it reduces in interprocedural data-flow analysis
     the analysis of programs with formal procedure calls to the
     analysis of programs without formal calls by treating formal calls
     as higher-order branch statements. We demonstrate that formal
     callability yields as a by-product the solution of the well-known
     formal reachability problem. This directly implies that formal
     callability is in general not decidable. However, we show that
     formal callability is decidable for programs, where formal
     procedure parameters do not occur in procedures, which are local
     to the procedure of their declaration (usually known as programs
     without global (formal) procedure parameters), but within a time
     bound which is exponential in the program size. Thus, we
     complement the new decidability result by introducing in addition
     a safe approximation of formal callability called potential
     passability, which can efficiently be computed. Moreover, for
     programs of mode depth 2 (i.e., formal procedures do not have
     procedures as parameters) without global procedure parameters,
     formal callability and potential passability coincide.

     Keywords: Formal callability, formal reachability, call graph
     analysis, interprocedural data-flow analysis, program
     optimization.

     Proceedings of the 1998 International Conference on Computer
     Languages 
     Copyright (c) 1998 Institute of Electrical and Electronics
     Engineers, Inc. All rights reserved.
       _____________________________________________________________

References

   1. http://www.computer.org/proceedings/iccl/8454/8454toc.htm#84540252
   2. http://dlib.computer.org/conferen/iccl/8454/pdf/84540252.pdf



David


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

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