RE: Native GUI (was Saving the System i: Fight Rather Than Switch)

ClickOnce doesn't deploy to clients unless the clients all run off a
network share.  Not reasonable for small branch offices or remote
workers.  It does seem like it could be useful if you're running IIS as
your web server infrastructure.  For workstations something like SUS
would be the more appropriate tool but it doesn't work across
non-WAN-attached devices.

A potential disadvantage I see is supporting such a beast.  If every
client's interface is done to their perspective as you say, then every
client has a potentially different look and feel.  I don't think this is
a help-desk friendly situation.  Granted, I haven't read the site in
detail so I could be wrong on this point.

Another is my ongoing point about remote/mobile deployments; No company
that has any concern about security is going to open ODBC to the 'net.
I'm also not about to buy a VPN concentrator that can support the
necessary number of concurrent connections.  That would be prohibitively
expensive compared to a couple hundred bucks for a 3rd party SSL
certificate & a few host CPU cycles to handle the encryption (or even
compared to buying the crypto accelerator).

And this approach is still not cross-platform.  If you're going to let
partners or customers access your apps, you have to be able to deliver
to every platform your partners use.  As often as Windows is that
platform, it can't be considered a guarantee.

John A. Jones, CISSP
Americas Information Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787 F: +1-312-601-1782
john.jones@xxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steve Richter
Sent: Monday, December 11, 2006 11:41 AM
To: Midrange Systems Technical Discussion
Subject: Re: Native GUI (was Saving the System i: Fight Rather Than
Switch)

On 12/11/06, Jones, John (US) <John.Jones@xxxxxxxxxx> wrote:

Mark,

I think the sticking point is that I don't think 5250 or fat clients 
are the way to go if one wants the iSeries to have a modern look & 
feel, which is what triggered this whole native GUI discussion.  And 
developing for more than one of the three options is by necessity 
going to take more resources (time/people/money) than developing for

just one.

Anything that takes more resources will reduce profitability unless 
one can demonstrate a positive ROI on the additional work.

Really, there's nothing inherently wrong or incorrect about any of the

approaches.  But if it's reasonable to expect a browser to be on the 
client and not reasonable to expect consideration to be made for a 
dumb tube, emulator, or fat client, then developing for the browser 
first and possibly only becomes obvious.

have not used it, but ClickOnce deployment might be the way to address
the problem of keeping all your desktop client software in sync and up
to date.
http://msdn2.microsoft.com/en-us/library/t71a733d(vs.80).aspx

A big advantage to not using the browser is the application can be
written entirely from the client's perspective and to their
specifications.  The central DP server department only has to provide
ODBC access to the system and documention of its interfaces.

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


This email is for the use of the intended recipient(s) only.  If you have 
received this email in error, please notify the sender immediately and then 
delete it.  If you are not the intended recipient, you must not keep, use, 
disclose, copy or distribute this email without the author's prior permission.  
We have taken precautions to minimize the risk of transmitting software 
viruses, but we advise you to carry out your own virus checks on any attachment 
to this message.  We cannot accept liability for any loss or damage caused by 
software viruses.  The information contained in this communication may be 
confidential and may be subject to the attorney-client privilege. If you are 
the intended recipient and you do not wish to receive similar electronic 
messages from us in future then please respond to the sender to this effect.