Dave Winer asks Who Do You Trust? This is a very important point, and I think its full implications may not be on the radar of the major news services yet.

Like it or not, we're in a war. Communication networks are a reasonable target. Taking control of large numbers of machines could cripple the network through massive coordinated denial-of-service attacks. I have not yet seen holes in the papers by Nicholas Weaver on Warhol Worm attacks. Spyware is relatively benign compared to seeding the world with computers which sleep until woken in a coordinated attack on the network.

You have to trust the code you're executing.

I trust that the network will eventually be able to deal with attacks, but my gut feeling is that we'll have to experience a significant attack until this point hits home, and it will then take time to secure each computer on the network. Long-term prognosis is good, but the short-term prognosis seems dicey to me.

You have to trust the code you're executing.

Location-Based Flash, on FlashMagazine: "Our guess is that you will take this kind of service for granted in about 5 years."

I agree. It makes great sense for consumers, and great sense for businesses. The technology is now coming into common play, and developer skills are progressing into this area too.

It wouldn't have to be a rich display... HTML or text can offer useful information here, even though it wouldn't be as rich or as interactive as SWF. Doing it all client-side would be costly, because you wouldn't want that thin portable client to do all the querying and formatting... you'd probably want to use server-side scripting so your client passes simple data, and then your big machine collects and formats all the data for the client. Runtime renderers, servers, and authoring tools all need to work together to make this new type of work cost-effective.

Exciting times. "Wow, grandpa, you really had to drive around and hunt for parking spaces, and then tell the waiter what you wanted before they started cooking it? Are you kidding!?" This kind of stuff could make me carry an extra six ounces of metal around in my pocket everyday.... ;-)

(btw, does anyone know FlashMagazine's detection scheme? It doesn't recognize my new plugin in Netscape/Mac.)

Macromedia Security Zone has a link to that IE/Win "cant stop streaming" problem. I wish we had the replacement Control up last week, but any release is a critical release so it had to be right before going out. Fortunately I haven't seen many posts where this has actually been a problem, although there is certainly great concern that it might be a problem sometime.

Thanks to Lawrence Lee for Rob Fixmer's eWeek article Internet Insight: Moore's Law & Order, which points out that Moore's law is not necessarily bound by a particular technology. ("Kurzweill's Law" reminds me of Robert Anton Wilson's Jumping Jesus Phenomenon... knowledge ain't just silicon.)

I firmly believe that more people will want to do more,more easily and cheaply, and that they'll be able to do so... I'm personally happy that this Macromedia MX initiative is pushing in the same direction.

Hole-in-wall proves functional literacy Thanks to Slashdot for the great story.

People have adapted readily to cell phones, messengers, more. Reproducible magic. Just as with connectivity, it's cheaper to offer unrestricted access to such enabling technology, thank goodness.

Eric Vitiello writes SVG: The New Flash in DigitalWeb Magazine. SVG is interesting in its own right; I don't understand why they keep on setting themselves up for failure by comparing it to SWF.

It's much easier to define a file format than it is to provide actual worldwide viewing capability... two very distinct problems, with very different levels of difficulty.

Vectors were only the first part of what SWF attempted, and these days the focus has shifted to rich internet applications.

Let SVG be SVG, that's the surest path to success.

CHris MacGregor did a quick usability study of delivery formats for short documents, with the tentative conclusion that SWF is 201.00% better than PDF.... ;-)

(I don't know why there are so many PDFs on the Macromedia site myself, despite the razzin' I give folks, but I do know a lot of people still live in MSWord.)

Taj Mahal Web site gets 'Flashed' This may show the tipping effect of having a ubiquitous capability... QuickTime is still a practical feature in browser-delivered work, but there's a difference between "destination" type pieces and "interface" type pieces. Different tools for different uses.

Hey, Flash 5 took the Codie for Best Software Development Product, cool.

On Documentation: Jarle Bergersen notes Russ Lipton's RTFM essay, and I think he asked if I was reading.... ;-) (I don't have commenting or permalinking built in to my routines yet, but this blog seems to be fitting various needs so I'll probably get more organized eventually. ;-)

I havent used the phrase "RTFM" myself, because when that message is received from certain places it's almost always a negative reception. It's easier for people to say it chummily to each other, but out of tech support, that advice would be disastrous.

I could see "Research The Fine Manual" in many situations, because sometimes just a peek into the index would be much faster than writing something somewhere and hoping someone else understands you and finds it worthwhile to reply and that you find their response and that that response was actually useful, but researching is an easier working style to assimilate than actually reading a book about what you'll be doing.

One dynamic about software documentation is that there are strong scheduling pressures to just document what the application does. Most people would rather read documentation of how they should work. But the people who write manuals have to wrestle mightily just to learn how the software will eventually work -- docs usually get frozen for press before the codebase is frozen, and they frequently have to write about features they cannot even see! It's a lot to document the tool by ship time, and much harder to document the eventual workflow people will use.

(Rephrased, there's a difference between "How does this menu item or dialog box work?" and "How should I work if I have to connect an ASP.NET backend between a DHTML interface and an ancient commerce system?" or whatever. The latter has more value, but the former is far more practical and achievable.)

We're seeing this pattern more these days because simple software applications like text-editors and early spreadsheets have been replaced by application development environments... documentation was easier when you worried about "How do I copy text?" instead of "How do I make an application which copies text?" It's a very different situation these days.

I'm with Russ's conclusion, that the tool vendor is best-suited to describing how the tool works, but that tool users are better suited to describing how the tool is used. We see this happening already today... UDZone, UltraDev Guru, heck here's a bigger list. There's a natural advantage in sharing knowledge.

That's part of what's driving this new Designer & Developer Center... folks out there know more than we in the shop do, but because we're in a central location it's our job to link all these smart people together, to help build that collective brainpower. In my group we don't know the best path to this, but we're trying multiple paths... any feedback about which types of resources work best for you would be great, thanks in advance.

Robert Occhialini notes a window component for Macromedia Flash from "amigo@modesite.net". I haven't dug into the code, but this illustrates some of the advantages of components: encapsulated functionality, familiar interface for site visitors, more development time for the overall design task rather than just implementation details.

But I'm sort of chagrined, too, because we don't yet have the next generation of the Macromedia Exchange ready. Because everyone who would be interested in a component knows the Macromedia site, this is the logical place to index into offerings from around the world. Such a central list can also help with issues such as component evaluation and developer compensation. But the current exchange was created long before the Macromedia/Allaire merger, and really needs to be updated to ColdFusion MX. That won't be ready for awhile yet, though... things may be cumbersome for a few months yet.

Mike Chambers discusses recent work from the Flash community in this week's DesDev articles. Other Flash-related news there include favorite features from Branden Hall, a new component for DesDev-style scrolling from Allen Ellison, more.

The DesDev Center has had enough issues to get a big backload of content, and we're hunting for ways to organize and present it to make it more useful for folks... feedback would be greatly appreciated in the discussion thread off of this article, thanks.

ZDNet on Photoshop: "In the longer view, the company is counting on Photoshop to help drive customers to other Adobe applications that work with the graphic package. Integration with Photoshop is touted as a key selling point for Adobe's InDesign layout software, which competes with market leader QuarkXPress, and its GoLive Web authoring software, which has struggled to wrest market share from Macromedia's Dreamweaver. 'We're making sure the file formats go relatively easily from one application to another,' Adobe CEO Bruce Chizen said in a recent interview with CNET. 'We do make it easier for our customers to use more than one Adobe product.'"

From what I've seen, I think GoLive will be trying to make it easier for InDesign users to get acceptable web publications, and the "Photoshop pushes GoLive" strategy isn't as big for them as it was two years ago...?

In the past there have been problems with data exchange with non-Adobe applications. I haven't tested Photoshop 7, but I hope its files go into existing applications same as before.

The "network publishing" story doesn't hang together for me yet... from what I've read they talk about "deploying content across multiple devices", but I think of "content" as a particular combination of data and presentation. The presentation layer should change with the particular delivery device. If you're going from a PDF document to a web page and to a handheld, would you worry about duplicating the same image at different resolutions, or would you worry more about whether each channel should have the same type of image content in the first place? If you're writing for print, would you want to just plop the same text up on the web? Keeping data separate from presentation is important, but "content" seems sort of a mix of the two...?

Carmen Nobel writes Flash Going Mobile in eWeek. Many portable devices will be able to use a rich client. I'm not convinced all will, though... some won't be strong enough for color displays, and some will have only a few characters' worth of data. The Macromedia Flash Player will be cool in devices which are strong enough to support it, but other parts of Macromedia MX will be needed for other portable connectivity tasks.

I wish Slashdot wasn't so hard to use. 383 comments? Something's not usable there. Meanwhile the original poster is trying to influence political restrictions on a multi-billion dollar false monopoly, and is worried about spending a day's labor for tools. Wacky.

Text, 99% Bad? ;-)