× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



From: "Loyd Goodbar" <loyd@blackrobes.net>
> I'm always on the lookout for more (and hopefully)
> better ways of handling web interfaces...

I'd better jump on your lead, Loyd.  It gives me an opportunity to explain a
bit about my framework, Relational-Web.  Programmers who have skill with ILE
languages may be interested.

In my opinion, there are a few essential requirements of a Web framework.
I'll list them.

Programmers shouldn't have to parse input from the browser.  They should be
able to simply reference HTML form variables, query string parameters,
environment variables, and cookie variables by name.

A change in the user interface should not require a change in the program.
For example, an RPG program should have NO imbedded HTML, XML, or
JavaScript.  There may be a few exceptions.  But as a rule, the framework
should support Model-View-Controller architecture.  User interface,
presentation control, and database / business logic should be in separate
source files.  It makes applications change resilient and easier to
maintain.

A single instance of a Web application may be supporting dozens of
concurrent users.  Therefore, the framework should make it easy to maintain
a session for each user.

The framework should make it easy for a single program to handle multiple
types of requests.  Most frameworks don't.  For various reasons, most CGI,
Net.Data, and Java programs handle only one type of request.  This often
leads to the redundant allocation of files and other objects across multiple
programs.

For example, a dozen or more types of requests may be required to implement
a database inquiry and maintenance program.  You could end up with a dozen
programs allocating the same files and other shared objects.

Highly interactive applications should run as servers.  Otherwise,
performance is poor.  CGI and Net.Data programmers can partially overcome
the performance problem through the use of named activation groups.

However, the use of named activation under the HTTP server has a few
downsides.  The programs themselves are trickier to write.  Memory variables
are not initialized from one request to the next.

With named activation, multiple instances of each program become activated
over time.  These instances are never deactivated until the HTTP server is
shut down.  For example, if the HTTP server is configured to run up to 40
threads and there are 100 CGI programs, it is possible to have up to 4000
CGI programs active after a period of time.  It puts an unnecessary burden
on OS/400 resource management.

A better idea is to enable an operator to control whether a program is
active or not.  For example, when you need to backup a database, you may
need to deactivate a program.  Any browser who tries to use a deactivated
program should immediately receive an alternative message (not the HTTP
Server timeout message a few minutes later).

Servers perform better.  For example, under stress testing (JMeter
www.apache.org), Relational-Web programs provide approximately double the
performance of Net.Data, and somewhat more than double the performance of
Easy400 CGI.  Even though the latter both use "named activation".  If anyone
is interested in the details:

http://www.relational-data.com/products/rweb/cgi/mainfs.htm

Best Wishes,

Nathan M. Andelin
www.relational-data.com




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.