|
Last issue I asked "Macromedia MX, what's the catch?"
I was surprised (but happy) that other people couldn't find a catch either. We did get some dings
on the current implementation though...here are the
top complaints I've seen in the newsgroups and mailing
lists in early May:
The preview release timed out early on my
Mac OS X box!!
Guilty as charged, sorry. This has been the hottest
issue on the newsgroups.
First, it's a big download, dozens of megabytes, which is frustrating
in itself. But if this big download times out early, then that's
particularly bad.
Any trial wrapper can turn itself off if your clock changes, or if there are
particular changes to the system while it's running.
These new trial wrappers for Mac OS X can also be
triggered by an Ethernet/Airport network change, whether
intentional or automatic by the system. The company
which makes the trial wrapper has confirmed this handling
with Apple, and will have a new trial wrapper available
by the time our actual release versions are ready.
The majority of people are using the preview releases normally—there's
about a 97% success rate—but that's of absolutely
no help if it times out on your machine.
These trial wrappers for Mac OS X are a very new area. If you made a big download
that you subsequently could not use, then I can only
offer my apologies, and the assurance that we've identified
the cause and this particular problem will be eradicated
by the time the actual 30-day trials arrive.
(Other Preview Release issues are documented in these technotes.)
Will ColdFusion MX run on my Macintosh OS
X Server?
Well, yes
and no, but not really, sorry.
Macromedia ColdFusion MX is indeed written in the Java language now, so you'll
be able to see some activity in an arbitrary Java
environment. Some on the mailing lists have already
written about being able to configure ColdFusion MX
and Mac OS X to be able to start it up and see some
parts work.
But we know there are other parts which definitely
won't work—the text-search engine is
built in native code, Enterprise Java Beans are not
supported by the Java 2 Standard Edition in Mac OS
X, there are no COM Objects to call upon, introspection
and proxy generation for web services are different—some-but-not-all
parts will work in an arbitrary Java environment.
Atop whether the application runs, there's the more important question
of whether it meshes seamlessly with other components: the web server,
various databases and drivers, any external process. This environmental
testing consumes a major portion of the work on any of the officially
supported platforms.
(This is similar to how you'd write DHTML to control audio or video in a
browser page...the JavaScript may be a standard language, but the
implementations vary across environments, and there's even greater variance
among the extensions used in those environments.)
What to do? If you're using Mac OS X Server in a production environment,
deploying pages to the world, then please let us know. (It could help our
beancounters if you describe how much you'd actually spend on ColdFusion!)
We're also tracking which databases people are using in such environments,
and which specific tasks they're trying to accomplish, thanks.
If you're just designing on a Mac, and then deploying to any of the
usual web servers, then you can use ColdFusion Developer Edition on one of
your local PC testing machines. You have to have those boxes for proofing
your pages anyway, so might as well get good use out of it by keeping your
app servers there too.
ColdFusion doesn't not work on a Mac, but it doesn't really
work there either...you can design for it on a Mac
easily enough, but for deployment I'd strongly recommend
one of the serving environments we specifically test
against.
Can I use Flash Remoting with PHP (or whatever)?
I have to
be careful what I say here, because we're currently,
uh, "between announcements."
What is "Flash Remoting? Jeremy Allaire says,
"This is a technology that allows you to expose objects and web
services on an application server as if they were local ActionScript
objects."
It's more compact and speedy than transferring information by XML, and
both the server and the distributed Player automatically handle data
serialization and deserialization.
Aside from the fast binary delivery format, the Macromedia Flash
Remoting implementation speeds development with debugging abilities,
session management, recordset management, high-level control for web
services, and similar amenities.
But do you need Flash Remoting? The universe could probably
survive without it, because you could do similar types of things by hand,
and with text-based XML transfers. Flash Remoting just makes such data
faster to transfer, and makes such applications much, much faster to
develop.
Flash Remoting is now built into every copy of Macromedia ColdFusion MX
and Macromedia JRun, and we've announced that it "will be available for purchase
separately at a later date". It is usually difficult to sell
products into the PHP market, but keep an eye on the Macromedia site, and on Mike Chambers' blog, for
ways that we're trying to complement text XML with this upcoming binary
AMF.
These aren't the only issues coming up in the newsgroups—there
are questions about pricing in the United Kingdom,
upgrade options, using RDS in Dreamweaver, the upcoming
video communications server, more—but the above
four issues were the hottest last week, each appearing
in multiple threads.
I'm still looking for overall "What's the catch?" issues with the
Macromedia MX strategy. We have HTML and SWF as the
two ubiquitous delivery formats, and are tying together
the server and the client (Flash Remoting), and tying
together the various servers in the world (web services).
To me it seems like we're all at the edge of a monumental
increase in what kinds of web applications we'll be
able to deliver to the public. But I need to understand
ways in which this reality could not come
to pass. If you've got qualms about the whole initiative,
then I'd really like to learn about what you see,
so drop a note here. Thanks!
|
