Re: Converting Program for Use on the Web?

From: J French (erewhon_at_nowhere.com)
Date: 02/25/04 

Date: Wed, 25 Feb 2004 14:09:52 +0000 (UTC)

Bottom posted

On Wed, 25 Feb 2004 12:17:32 +0100, "Bjørge Sæther"
<bjorge@hahaha_itte.no> wrote:

>J French wrote:
>> On Fri, 20 Feb 2004 19:26:04 ?, "Maarten Wiltink"
>> <maarten@kittensandcats.net> wrote:
>>
>>> "Bob" <ttsupprt@pacbell.net> wrote in message
>>> news:J99Zb.27786$c7.24601@newssvr25.news.prodigy.com...
>>>>>> - What is "stateless" or the implication of stateless?
>>> [...]
>>>>> A Web interface is an entirely different beast from a window
>>>>> interface, and "state" is what makes the difference. To the best
>>>>> of my knowledge, the problem has not yet been acceptably solved.
>>>>> Perhaps trying is a mistake.
>>>
>>>> Maybe "trying" will lead to an "acceptable solution"?
>>>
>>> Okay, I skipped a few steps there. What I meant is that the mismatch
>>> between the two paradigms might be such that it really cannot be
>>> resolved. As an old EE prof said, he once tried for a full day to
>>> construct a parallel algorithm for integer division - and ended up
>>> proving mathematically that it couldn't be done. I have a very
>>> informal hunch that all attempts to implement a stateful interface
>>> on a stateless engine are doomed to begin with.
>>
>> You can 'store' the state in hidden submit fields
>>
>> You can also 'remember' prior transactions and get back the data from
>> ... typically a key kept in hidden submitfield
>>
>> However, in principle, yes, writing for a Web interface is radically
>> different from writing for a 'standard' interface
>> - oddly, I am inclined to think that we can learn a lot from the
>> problems of writing for a Web interface
>
>Indeed. While the "state" of a Windows application may be determined by what
>form has currently input focus and the current value of controls, we all
>know that this is far from a perfect scheme for creating an application. In
>its simplest form, a web interface to an existing Windows application would
>look something like a remote controlled windows application. This is of
>course not desirable, as it both wastes resources and introduces the "GUI
>hell". Removing the functionality from the form units and maintaining state
>in other objects than the forms is a good start.
>
>Now I was assuming a stateful application. I believe I've never written an
>application that would easily be converted to a stateless one. My solution
>would be creating two applications: The stateful, converted win-application,
>and a <50kB stateless wrapper application having the following
>functionality:
>- Check whether there is a running instance of the stateful application
>which is running the session identified by the ?SESSIONID=XXXX parameter
>from the url (by enumerating processes, using FindWindow or similar)
>- If so, pass the url onto this instance by messaging or similar
>- If not, start an instance
>- Wait for returned HTML data from the stateful application
>- return the html in stdout
>- ...and be unloaded again.
>
>The stateful application will run for XX minutes before it's automagically
>shut down.
>
>Ideally, one should be able to describe the "state" of a stateful
>application in therms of a number of parameter values, start up the
>application and return to the described state. This may be very hard....;-)
>
>Just my 2cents...

Text left unsnipped deliberately

This is an interesting problem, and when faced with it I took a
different path

I understand 'State' as in 'State Machine'
- where the 'Machine' is a pure input output device
- eg: it remembers nothing
(this is probably an extension of the real definition)

Personally I would cut your App into two parts
- the real App
- and Notepad

With the sophisticated features of Notepad, create an INI file, and
then pass that to your App
(obviously one that is up and running)

Web based Apps are probably very similar to the old Terminal 'Accept'
based systems of many years ago.

... Or those things we used to write in the DOS days
- moving seamlessly from one EXE to another, passing all parameters in
a form of INI file on disk or in reserved RAM

Relevant Pages

  • Re: Converting Program for Use on the Web?
    ... > However, in principle, yes, writing for a Web interface is radically ... While the "state" of a Windows application may be determined by what ... Now I was assuming a stateful application. ...
    (comp.lang.pascal.delphi.misc)
  • SQL Server - Access synchronization
    ... I have a VB app which stores information in an Access 2000 db. ... We're adding a web interface to the package - basically a scaled down data ... initiate the synch from their workstation. ...
    (comp.databases.ms-sqlserver)
  • Re: web interface
    ... I want to provide a web interface for this app. ... The app is computationally intensive and may take long time for running. ... class LongTaskPage: docFactory = loaders.stan(tags.html[ ... var resultNode = document.getElementById; ...
    (comp.lang.python)
  • Re: Best GUI for small-scale accounting app?
    ... >> What does the app need to do? ... Making the web interface look really good might be harder ... and applications that can't stand that redisplay are an example ... of a good reason not to use a web interface. ...
    (comp.lang.python)
  • Re: web interface
    ... I want to provide a web interface for this app. ... The app is computationally intensive and may take long time for running. ... You can simulate the feel of a desktop application to some extent by having the output of the starter page redirect the user to the poller page, and having the poller page refresh itself periodically. ...
    (comp.lang.python)