Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Cross-platform

 [1/4] from: rebologue::yahoo at: 8-Aug-2002 17:36


Atruter said: [cross-platform code] just doesn't make commercial sense in many cases... remember that these tools are designed to make things easier for the *developer* not the end user. I have to agree with Ashley here, at least in the context of client apps. Commercial success in this space is a difficult balance of technology, marketing, service, support and usability. Oh, and luck. While I agree with Joel that a developer's burden often translate into user woes, that statement is hard for anyone to disagree with. Now cross-platform code doesn't exactly address that problem, right? It's likely that Joel was referring to server-based apps. The cross-platform feature is much more prominent issue there. To please the market for server-based apps and CGI, a product usually needs: * reliability * speed * scalability * acceptable security * cross-platform support * support for standard integration interfaces (protocols, security, etc.) With client apps, the list of priorities is much different: * familiarity (native look & feel) * responsiveness (speed) * functionality (features) * usability * interoperability (integrates with platform and plays well with other apps) On Windows, a technology that fails to address each of these points might be better off as shareware or open source. An exception to this rule could be made for killer-apps such Netscape or Napster (and were boosted by the fact that they were also free).
>From a business and user perspective, many proprietary
platform features add value. Such as the ability to display a spreadsheet inside a word-processing document, or drag a file icon from the desktop into another app. The evil side of that is lock-in, but that's a fundamental business reality and hollerin' won't make it any less so. So what now? Give developers the tools that give users the no-compromise client-experience they expect. At the same time, eliminate the developer headaches and bloat required by other tools to achieve that same high-quality experience. Offer me that and you've got something **most** developers would willing to pay serious money for. No other company has really delivered on this yet, which is why it remains an opportunity. Hey, I've got the perfect product to sell in the US, but it requires Americans to switch to the metric system, lose weight and drive electric cars... I'm betting this will be the next big thing... ;^) // Ed

 [2/4] from: gscottjones::mchsi::com at: 9-Aug-2002 6:44


From: "Ed O'Connor"
<snip> > Hey, I've got the perfect product to sell in the US, > but it requires Americans to switch to the metric > system, lose weight and drive electric cars... I'm > betting this will be the next big thing... ;^)
LOL. It is good to be able to laugh at ourselves sometimes. Thanks for the morning chuckle. --Scott Jones

 [3/4] from: joel:neely:fedex at: 9-Aug-2002 10:09


Hi, Ed, Ed O'Connor wrote:
> Atruter said: > "[cross-platform code] just doesn't make commercial
<<quoted lines omitted: 5>>
> space is a difficult balance of technology, marketing, > service, support and usability. Oh, and luck.
I'd suggest the paraphrase: ... these tools are designed to make it easier for the developer to give the end users what they need, and to keep in working/growing with a minimum of effort.
> While I agree with Joel that a developer's burden > often translate into user woes, that statement is hard > for anyone to disagree with. Now cross-platform code > doesn't exactly address that problem, right? >
Sure it does, as illustrated by another anecdote from my checkered past. Imagine a system where Box A is running an information system directly supporting end users. Box A gets a regular FTP feed from Box B to keep some critical data up to date. (There was a relatively slow business cycle involved, and some correlation with other stuff was done on Box A, so there was no point in doing this via a live, up-to-the-nanosecond database connection. In fact, that would have been even more disastrous, as you'll see.) The owners of Box B (in a different department) decided to replace Box B (running Unix) with Box B' (running a well-known proprietary O/S). However, they configured accounts and FTP on Box B' using some proprietary nonsense that broke the running FTP fetches on Box A, and broke it in a way that the nature of the problem was not immediately obvious. Work was required on both sides to diagnose and fix the pointless, proprietary-environment-induced interruption of service. There are any number of things that could have been done differently by the owners of Boxen B and B' to have avoided this waste, and essentially all of them involve either using cross-platform tools or at least understanding and conforming to platform-neutral standards.
> It's likely that Joel was referring to server-based apps. >
Not really. The phrase "server-based" should be a deployment strategy and performance tuning matter, rather than a basic consideration. In an increasingly networked, object-oriented world, we should be able to migrate objects, services, logic, components, etc. as appropriately (even dynamically) to deal with performance concerns, fault-tolerance/recovery, etc. By artificially drawing a boundary between "client" and "server" we introduce unnecessary distinctions. In addition, the view of the "web services" world is that one physical system may be a client in one transaction and a server in another transaction where both transactions are parts of a larget application process. Again, migration and portability end up providing a degree of flexibility for configuration and resource allocation that IMHO benefits everybody (whether they see it directly on a daily basis or not). -jn- (As usual, my opinions are my on, and do not reflect the position of any other party -- including myself 24 hours later! ;-)

 [4/4] from: rebologue:yaho:o at: 9-Aug-2002 9:55


Hi Joel-- Cross-platform code aids developers in cases where the required solution is to port code to a new platform. Not a real boon the rest of the time, other than the comfort of knowing that you've got easy migration options. I'm taking a micro-leap of faith in asserting that migrations of this type are more common (and critical) for server-executed code than for client apps. 15 or 20 years ago, I'd say that cross-platform code was key to ensuring survival of client-side apps. No so much these days. The present world is now dominated by highly adaptable survivors such as pidgeons, cockroaches, McDonalds and Microsoft Windows. Joel Neely wrote: ---
> By artificially drawing a boundary between "client" > and "server" we introduce unnecessary distinctions.
Bzzzzt! I need to buzz-in on you here. Good stuff, and we can speculate that it will be more relevant in the grand "one degree of separation" future, but still a bit of a digression. I use the terms client and server because we're all familiar with the terms/concepts. I provided a list of important criteria for successful software, and that cross-platform code addresses one of those items. I'm not attacking the importance of cross-platform code, just putting it in perspective. I mean no disrespect, Joel. Your participation and support of Rebol over the years has helped me immeasurably. I'm sure many on this list would say the same. // Ed

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted