|
Browser based apps can make sense; but most are slower that a telnet or native GUI application would be. Also, they consume more server resources as well. It is true that html is easily sniffable as a previous poster mentioned; but the same is true of almost all unencrypted traffic. This would only be a concern if you client uses SSL secured telnet. Also, it can be difficult (not impossible) to do some common things native applications do in html; if you use an applet or activeX you can easily get around most of them; but then you go back to many of the problems of a native application. Some examples: A page that will need to scroll to show all the data in "grid" style format; you need to keep the column headers visible. You need to manipulate the data you are displaying without rerunning the select You need to validate input against a large table without refreshing the whole interface You need to run a job that will take longer than 1 minute Security design; rather than using a native user security model as you would with a native application you usually roll your own for the web; this can be pretty difficult 2 words; SQL injection - can be a problem for native applications; will be a problem for your web application You need to run a "restartable" job You need the ability to "cancel" once a page has started Another point is system management. It can be (depending on how your application is written) difficult to find any information about performance or errors. The HTTP webserver logs are all but useless (Windows or i5) for diagnosing server issues with your application. That means you have to handle your own logging. Once again it is do-able; but you have to think about it before your application is developed. -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John Earl Sent: Wednesday, December 29, 2004 9:36 PM To: Midrange Systems Technical Discussion Subject: RE: Why NOT the web? Art, > I have a customer that wants to re-develop their entire "ERP" solution > using .NET. <snip> > Actually, when I say web, I mean browser based. They will use IE. > > I've told them that the web is not for this kind of stuff, it's for > customer service, inquiries, simple ordering,etc. I think there are two separate issues here - 1) should they move internal applications to a browser based interface, and 2) is .Net the right way to do it. I don't agree that a browser based interface is not right for internal applications like the ones that you describe. Browser interfaces are usually instantly recognized and comfortable for new users of your application. They allow you to provide additional dimensions to your application trough hyperlinks graphics, video and sound. And they offer fantastic Help and FAQ opportunities. And not to overstress the value of hyperlinks, this is an awesome way to quickly link parts of an application together in a flow that matches the users work habits 9much better than Menu options). IMHO, you ought to consider putting a browser interface on all of your apps - and continue to run them on the iSeries. As for .Net - well I don't know much about it, but I have seen a variety of instances where the iSeries (or even better, the i5) renders HTML and Java applications beautifully. And since the bulk of your corporate data is already there, doesn't it just make sense to render it from the iSeries rather than moving it, replicating it, or adding another architecture tier? I don't think that the argument is browser vs. 5250 telnet, it's really i5 vs. .Net. eServer i offers many, many, benefits over Wintel architectures. But if you cast the battle as browser vs. 5250, I think you'll lose the argument before you ever get the opportunity to discuss any of the iSeries benefits. JMHO. jte -- John Earl | Chief Technology Officer The PowerTech Group 19426 68th Ave. S Seattle, WA 98032 (253) 872-7788 ext. 302 john.earl@xxxxxxxxxxxxx www.powertech.com This email message and any attachments are intended only for the use of the intended recipients and may contain information that is privileged and confidential. If you are not the intended recipient, any dissemination, distribution, or copying is strictly prohibited. If you received this email message in error, please immediately notify the sender by replying to this email message, or by telephone, and delete the message from your email system. -- -- 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 mailing list archive is Copyright 1997-2025 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.