× 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.



Vern,

Thanks for your response and kind words about our student information
system. We have updated and extended the look, feel, and functionality
since that video was produced (seems dated to me). But thanks for making a
reference.

I agree that there is a good business case for OA handlers and products
like Profound UI. I hope my posts don't come across as challenging your
preferences and priorities. Mostly, I would like people to be aware of
alternatives and their respective trade-offs.

Regarding the Profound UI client, the word "applet" was the best I could
come up with. It is approximately 650 KB in size, is downloaded in a web
page, it initiates communications with the OA handler on the server, and
implements a communications protocol. It's more apt to call it an
"application" than a "framework". It works much like a 5250 emulator,
except the I/O streams are more robust. Granted it is written in
JavaScript; not Java.

Thanks to Scott, I better understand how <iframes> might be used to
reference separate OA JOBs from from separate <iframes>. I prefer an
architecture where a single job may service simultaneous requests from many
<iframes>, each frame having a shared context; the same "session", if you
will.

It is a challenge for me to advocate a modernization strategy which
includes removing, refactoring, replacing, and rewriting code. Most people
view that as costly, time consuming, and risky. We have successfully
implemented a framework which addresses those concerns.




On Wed, Jun 10, 2015 at 9:36 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

Hi Nathan

I've waited to respond to some of your comments - I did make a point of
going out to your company's site and watched the video there on your school
administration software - makes a good impression and seems very useful.

I've put my comments inline - just a couple here, mostly about OA and
applets.

I understand your point about refactoring and all - and I find a
compelling value in something that will provide a more modern interface
without needing to change any (or all) code RIGHT NOW!! I can say from some
queries I've made here, that just the browser interface of 5250 would make
a huge impression of being on a different, more modern system. The
ability, basically, to flip a switch over a weekend is very attractive to
us. AND the ability to modify and enhance as we go, seems much more
cost-effective.

I suspect we will have philosophical differences here - hence this has the
potential for being a religious argument - Q.E.D., not to be continued too
much longer, mehopes~~

Regards
Vern

On 6/10/2015 9:24 AM, Nathan Andelin wrote:

You have heard my name before, haven't you?


Scott,

Thanks for the reply. Of course I know who you are. Seems odd that you'd
ask. I wasn't preaching to the choir. My posts are for everyone. Sorry if
it seemed like me singling you out. I was suggesting that shops which are
gaining greater awareness of the technical debt in their legacy systems
are
more likely to look at web application architectures other than "display
files" and OA interfaces.


OA interfaces do not exist. OA is a mechanism, a technology, if you will,
for redirecting the RPG runtime to use something other than the database
services on the system to perform IO operations.

You said in a reply that "...having multiple frames in applications
doesn't fit with an Open Access architecture..." - I submit that it can,
since it seems Profound is doing so - details I do not know, of course, so
it may and likely does differ from how you use them - that's fine.

I just think this categorical statement displays a misunderstanding of OA,
that's all.

Regarding "applets", consider definitions from www.dictionary.com:


I don't know about dictionary definitions for "applet" - the ones cited
seem slanted toward a program - that feels external to the web page itself,
whereas Javascript, including libraries, seem to be more internal - picking
at nits, I'm sure.

I will claim to be a little more than a dilettante in the web world -
probably not MUCH more - but, in every place I've heard the term, applet
has been tied to Java.

Distinctions blur, since things like JQuery need to be downloaded, too -
still, they are more like /copy and #include, which makes them more a part
of the page source than an external object.

-snip-

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



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.