«

On Tue, 26 Jul 2005 09:16:57 GMT, Spartanicus <>
wrote:

>You are violating w3c guidelines by serving XHTML 1.1 as text/html.

Oh, get a life !

Who cares ? Apart from anything else, the guy's clearly a Furry, which
is a far worse crime.
http://sinfest.net/comics/sf20050726.gif


AJAX is interesting. Now if you have nothing to add
_on_the_subject_of_AJAX, then shut up.

On 26 Jul 2005 03:51:53 -0700, "Travis Newbury"
<> wrote:

>For me, the jury is still out on AJAX.

The jury has already decided - maybe you don't agree.

>I am finding very little advantage
>over doing the same thing with Flash.

It's the difference between semantically-aware HTML and a <table> full
of text rendered as bitmaps. They both work, but one is an opaque pipe
that only works when connected to one particular endpoint. The other is
a transparent pipeline where you can swap components around in the
future.

One nice thing you can do with AJAX is to handle business logic with it.
You can describe business logic and run it on the server. Then you can
take this same description and use it to generate an AJAX client app
that emulates the same behaviour client-side. Or even better, you can
have a transparent client query the server from within the page, so as
to use the server to actually execute the logic. You could do this with
Flash (and friends) too, but you'd have to do three implementations.

On Tue, 26 Jul 2005 20:17:18 +0200, Lasse Reichstein Nielsen
<> wrote:

>Man, that game sure is network hungry.

A common problem with AJAX apps that aren't carefully designed to avoid
this. AJAX kills servers because it encourages round-tripping to the
server for the most trivial user events.

wrote in
news: oups.com:

>
> FFS, when will people here stop being so bloody anal about this
> stuff. The work that Woollymittens has submitted, because it may be
> of interest, isn't compulsory reading. So, if the text is too small
> for you, either do as he suggests and change the size in your
> browser, or **** off to another site that uses 48pt Sans Serif.
>
> Instead of smart arse responses like yours, why not make an effort
> to read the content and offer some contructive feedback.
>
> alt.html used to be a cracking group. Now it's degenerated in to
> the slop that is/was CIWAH. A bunch of in-crowd know-it-alls that
> are simply here to inflate their egos by stomping on others. I know
> - I've done it too, but now it's tiresome.

Wow. And this just happened to be the second post I read in here for
quite a while. Thanks.

Andy Dingley wrote:
> On Tue, 26 Jul 2005 20:17:18 +0200, Lasse Reichstein Nielsen
> <> wrote:
>
>
>>Man, that game sure is network hungry.
>
>
> A common problem with AJAX apps that aren't carefully designed to avoid
> this. AJAX kills servers because it encourages round-tripping to the
> server for the most trivial user events.

You're right at that. Like rSS feeds, AJAX isn't supposed to be more
efficient at anything. It's more convenient in some situations, that's
all. Until servers can push informations to clients, pulling updates
periodicaly is the only way.

Then again, this is a game, it's allowed to be hingry. The only thing
flying up and down is updates, not whole game states.

For instance. Every 4 seconds it asks the server for an update. And you
get the hit on your ships, your current money and any new chats.
Offcourse if you DO more, you get more replies.

One could argue that instead of getting 10KB worth of HTML at a refresh,
you're getting 10 times 1KB of updates. One can make it as heavy or
light as one wishes.

Woolly

Andy Dingley wrote:
> On 26 Jul 2005 03:51:53 -0700, "Travis Newbury"
> >For me, the jury is still out on AJAX.
> The jury has already decided - maybe you don't agree.

I am not making a judgement on the technology, only my use of it.

> >I am finding very little advantage
> >over doing the same thing with Flash.
>
> One nice thing you can do with AJAX is to handle business logic with it.
> You can describe business logic and run it on the server. Then you can
> take this same description and use it to generate an AJAX client app
> that emulates the same behaviour client-side. Or even better, you can
> have a transparent client query the server from within the page, so as
> to use the server to actually execute the logic. You could do this with
> Flash (and friends) too, but you'd have to do three implementations.

Why would you have to do 3 implementations? One of out best selling
Flash applications (a live or on demand training/simulation
application) is completely data driven to include the creation, size,
placement, and content of objects on the screen. The developers use a
(VB.net) application to describe what they want (both layout and
content), it creates the Flash configuration (either XML or a table in
the database depending on the needs). The Flash object when it opens
reads the configuration from the XML file or the database, configures
itself (look and feel as well as functionallity) then runs. Business
logic resides on the server where it belongs. We support
ASP/Access/SQL Server or PHP/MySQL

There is no timeline, no layers, and no objects in the raw Flash
object. Only actionscript. This has the additional advantage of being
VERY small (49K if you use Media player for your video, 79K if you use
FLV video) so a Dialup connection is not a problem even with a very
sophisticated training course. The FLV video version will also run on
ANYTHING that supports Flash-7.

--
-=tn=-

Travis Newbury wrote:
>
> Why would you have to do 3 implementations?

Because I can and you won't and the customer likes to hear that.

Woolly Mittens wrote:
> > Why would you have to do 3 implementations?
> Because I can and you won't and the customer likes to hear that.

Actually I was commenting to Andy (I think) who said I would HAVE to do
3 different implementations if I did the same thing with Flash. I was
disputing the "HAVE TO" part.

--
-=tn=-

Travis Newbury wrote:
> Woolly Mittens wrote:
>
>>>Why would you have to do 3 implementations?
>>
>>Because I can and you won't and the customer likes to hear that.
>
>
> Actually I was commenting to Andy (I think) who said I would HAVE to do
> 3 different implementations if I did the same thing with Flash. I was
> disputing the "HAVE TO" part.
>

Oh sorry... I'm getting flameblind, with all the pro/contra flash
propaganda flying around. Personaly, I really dislike developers who
aren't openminded enough to see fitting solutions on other platforms.

Here I am, working for a microsoft gold partner, developing a webgame
optimized for Firefox using AJAX instead of "callBacks", playing sound
from a flash plugin. Life couldn't be more complicated. =^.^=

On 27 Jul 2005 03:40:28 -0700, "Travis Newbury"
<> wrote:

>Why would you have to do 3 implementations?

Three implementations - good.

Effort of doing three implementations - bad.

Lets see how we put the business logic in our three different places: on
the server at form submission time, on the client, and on the server and
being used interactively by the client (through AJAX).

Now you can do any of these through a Flash-based front end too (been
there, did that with XML-RPC a couple of years back). But the problem is
that you're writing new code for each one. The first is in J2EE (or
whatever), and the second is in pure Flash. There's no way to go from
one to the other without re-coding by hand. The third one is even more
awkward - you need to integrate the two platforms and you're all on your
own for how to do it.

AJAX is a defined route. No matter how I back end it (apart from .Net,
which will obviously get it deliberately wrong) then I'm looking at the
same AJAX platform. From my client-side code, I see the same tools and
interface to code to. From the back end I see an integrated path that
can migrate my business logic almost dynamically, on demand of the user
and their particular platform capabilities for that session.