Re: Thick client/Rich Client was->RE: Saving the System i: Fight Rather Than Switch -- MIDRANGE-L

AJAX is great stuff but there are still things that need looking into.As more and more exploits get launched from Javascript enabled browsers,I expect some backlash . You may have corporations that lock down theuse of Javascript in their browsers, negating some of the benefits ofAJAX. This is an area where I see traditional RPG programmers, meincluded, as well as most casual programmers in any language, needadditional training and vigilance. There is an interesting articleabout Javascript security here: http://www.adtmag.com/article.aspx?id=19036

I never had to give much thought to security when writing an RPG programin the "classic" twinax environment. At least, not much thought beyondobject ownership and access. When TCP/IP allowed 5250 telnet sessionsto be used, things got more interesting. We added SSL to encrypt thedata stream, but 5250 apps in RPG still provided a fairly secureenvironment. Things get interesting when we move to HTML andclient/server applications because now we have the possibility of SQLinjection, session spoofing, and many other techniques that stem fromthe user's ability to manipulate the HTML content or the URL string todo malicious things. Carefully written server side applications canreduce the chance that bad data can do bad things but we still havebuffer overflow type exploits that use weaknesses in the server code itself.

AJAX isn't the cause of these things, but it can be just as easilyexploited. My point here is that implementing something like AJAX iseasy, securing it takes careful design. We need to get more experiencedin securing our web applications. Otherwise, we may find that ourcustomers disable features our code relies on, negating the benefit ofthe approach.


Much to learn.  Much to do.

Pete


albartell wrote:

Now I'm really wondering just how far AJAX will go?  Will it be possible to

deploy applications to servers that provide desktop-like features (like
WDSC), but great performance  (like 5250), without the problems of managing,
maintaining, securing, and synchronizing obese desktop environments?

Good question Nathan.  I am seeing some pretty neat stuff done with AJAX
with the following site being one of the most impressive.

http://www.zimbra.com/products/hosted_demo.php

There are a boatload of requests going back and forth to the server, but the
requests are a lot small I would imagine.  So we are kinda shifting the role
of a server to be more DB and CPU focused vs. data throughput.  I imagine
the AJAX frameworks will only ever get better making it easier for
developers to develop kick butt apps like this.  I would be curious to know
how long it took them to develop this and how much of a "framework" they
built around it or if they used an existing open source framework.

Aaron Bartell

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Friday, December 15, 2006 6:43 PM
To: Midrange Systems Technical Discussion
Subject: Re: Saving the System i: Fight Rather Than Switch

Trevor Perry Wrote:
CTRL+S in WDSc is publishing your changes from the
development server to the deployment or production server.


Man, I didn't mean
to spark a debate between WDSC and PDF.  I understand the Eclipse community
is promoting the term Rich-Client Platform (or RCP) for Eclipse based
plug-ins and applications like WDSC.

Some years ago I
dove head first into desktop and client-server development using Visual
Studio, Visual Foxpro, and Delphi.  VB and Visual Foxpro compilers created
small .exe files, but required runtime .dlls of 1.5 - 2.5 meg.  Delphi
created self contained .exe files that ranged in size from a about 3kb and
up.  My biggest  Delphi application was about 4MB.

In client-server
settings we normally used ODBC to access SQL databases, which might be
deployed on remote servers.  Performance of ODBC was constrained by network

bandwidth.We adopted the term Fat-Client, which was unflattering, but appropriately

fit the architecture.  Most of the application logic was deployed to the
desktop, which was a pain to manage, maintain, secure, and synchronize with
server based file systems.

If I understand
correctly, the minimum RCP footprint is about 7MB, and deploying an
application on top of that will perhaps double the footprint, and being
written in Java, my guess is that the memory requirements would be about ten
(10) times greater than the desktop applications that I used to develop.  If
they were fat, wouldn't that make RCP obese?  I don't know the footprint of
WDSC, but it seems to be huge.

Rich sounds more
appealing, of course.  But where did the term Rich-Client come from?  And
why was it adopted by the Eclipse community?  The first time I heard it was
in connection with AJAX technology, then later with Adobe Flex, which are
both browser-based technologies.  Flex applications run in a small browser
plug-in, while AJAX just runs in the browser.  Did the Eclipse community
hijack the term?

One day I was
composing an email, using Yahoo's browser based interface, when I noticed
that about half of my words had squiggly red lines underneath.  What's all
the red, I wondered?  I tried clicking on one of the words and was
immediately rewarded with a small popup list containing similar words, but

having correct spelling.It turned out that some asynchronous process in Firefox was evidently

running a spell checker while I typed.

Now I'm really
wondering just how far AJAX will go?  Will it be possible to deploy
applications to servers that provide desktop-like features (like WDSC), but
great performance  (like 5250), without the problems of managing,
maintaining, securing, and synchronizing obese desktop environments?




Nathan.


----- Original Message ----
From: Trevor Perry <tperry@xxxxxxxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Friday, December 15, 2006 9:52:18 AM
Subject: Re: Saving the System i: Fight Rather Than Switch

Nathan,

Thanks for the support. I appreciate the feedback.

Maybe I need to build a website: www.as400syndromeandproudofit.com ? I agree
with you that the key to the future is leveraging the past. However, we need
to have a clear vision of what was valuable from the past and use it as a
stepping stone to the future.

For example, you compare SAVE in SEU with CTRL+S in WDSc. However, these
things are two completely separate tasks. SAVE in SEU will save you current
member for you to your development system. In WDSc, this function is done
for you. Your PC is the development system, and it keeps all of the changes
you make as you develop in the Integrated Development Environment. CTRL+S in
WDSc is publishing your changes from the development server to the
deployment or production server.  Not apples to apples. You are complaining
about the present based on something different from the past.

And, you did not define what you meant by 'better' when you said "native
record level access is better than SQL for retrieving records by key,
updating them, and writing them". While the AS/400 faithful may think it is
'better' in some green outdated sense, the System i futurists do not agree.

Trevor







__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
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.