|
Hi Ted, At the risk of offending you ... the more
people shout, the less I listen to them. I totally agree with you (again!) that FDS
is much more than just remoting. And if the solution requires the other
features of FDS (that webservices cannot provide), FDS is a good option to
choose. Pricing might be an issue, but in the area (financial services) I work
in, I don’t expect it to be a real issue. If the requirement of your software
project is indeed to support client PCs from the previous century, of course
you need to check what the user experience is on those machines (again: that’s
the only driving factor). For me, this does not apply, since the applications I
build are 90% intranet applications (enterprise administrative systems); these
environments normally do not have so many problems parsing an XML message. I always strive to build my solutions on
standards and don’t want to rely on proprietary frameworks and tools, when I
don’t need to. It gives me freedom and makes me more resilient to change. So,
for the last time, in my area I don’t see the need for messaging and data
management (2 of the 4 major parts that you mention), and so far I have not
suffered from any user experience issues due to the usage of webservices (point
4). Remains the productivity issue (point 3).
For that I am willing to pay the price of choosing a standard instead of
locking into a proprietary framework, since I believe that it will not drive up
the total costs of a software development project significantly. To your question ‘Would non-flash clients
for AMF and Messaging help?’ ... I don’t think so. AMF will never become a
standard like webservices are now. Pushing AMF as a new remoting standard would
be a big mistake. You’d burn a lot of money with probably no success. Maybe this will sound strange now, but I
am no great fan of web services. I think it is a lousy technology. But it’s the
technology that the big industries are standardizing on now. And that’s the
great benefit. Although the technology is lousy, it does its job. There are
interoperability issues, but in due time they will be fixed. After the journey
of RPC, CORBA, RMI (and other proprietary communication protocols ... I
remember PowerBuilder had its own as well), I hope that web services will be
the final technology that will be settled on. Then, we can start focusing our
valuable time on the business at hand and not on the exchange of data between
client and server, which should be something trivial. By the way, writing that last paragraph
made me wonder why Macromedia did not choose RMI for the remoting protocol, but
have you chosen to develop your own (AMF)? Cheers, Franck From:
[email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Ted Patrick Frank, -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
YAHOO! GROUPS LINKS
__,_._,___ |
- RE: [Junk E-Mail - LOW] [flexc... Jack Caldwell
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of ... hank williams
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Dustin Mercer
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of ... Evert | Collab
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Evert | Collab
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of ... Franck de Bruijn
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... hank williams
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Tom Lee
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Franck de Bruijn
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of ... Bjorn Schultheiss
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Franck de Bruijn
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Bjorn Schultheiss
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Tom Lee
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Franck de Bruijn

