[jdev] Jabberd2, Flash Client and terminator character...
Richard Dobson
richard at dobson-i.net
Mon Apr 12 13:52:18 CDT 2004
> This now seems OT, and it's not my job to try to convince you that Flash
> is more than you think it is but:
Of course, and I doubt you will be able to convince me since you dont seem
to be listening to what I am saying so there is not much point continuing
this here, lets just get onto the relevant subjects in hand.
Overall as has been said because of the limitations in Flash there are
several options in order of preference.
1) Lobby macromedia into if not providing proper jabber support into
providing a more flexible xml parser system that can support xml streams,
and into providing a more flexible sockets infrastructure, this will mean
full compatibility with standard Jabber/XMPP servers.
2) Use JEP-124 HTTP polling, this will also mean using a standard protocol
and so will work with most Jabber/XMPP servers that have deployed this, and
does not require any flash custom hacks which as others have noted are a
very bad thing to propergate now we have proper standardised protocols.
3) Create a proxy between Flash and the Jabber/XMPP server, this means
either you have to rely on server admins to install this gateway with their
jabber installtions (an unlikely possiblity IMO) or you (as the flash
application developer) have to host it yourself.
4) Lobby the jabberd2 developers into implementing the flash specific hacks
that are against the established protocol specs, this is bad because it
propogates bad hacks, it also means your flash apps will only work with
jabberd2 servers and will not work with all the other jabber/xmpp
implementations out there, also your flash apps might stop working sometime
in the future if these hacks get removed or changed. Overall this is the
worst possible solution to the compatibility problem.
If you feel the need to reply to my comments on the below I suggest further
replies on these topics are direct to me rather than the list as it is
getting rather off topic with all the extra things you are introducing into
the discussion.
> 1) Flash is not limited to XMLSockets. It has full access to SOAP,
> WebServices and AMF, a binary remoting format. We use AMF remoting to
> connect to our Java services, running on JBoss, to transmit DTOs back and
> forth with seamless translation of the binary objects between both sides.
> The only thing I use XMLSocket for is Jabber.
I know all about the SOAP stuff etc but this still doesnt help with flash's
lack of extensibility of basic things like sockets and xml parsing (i.e. it
doesnt work with jabber xml streams when it should have some way of working,
e.g. SAX style parsing).
> 2) Flash is better for complex UIs, especially since development time is
> much faster. You can't build in JSP/Struts what you can in Flash. And
> Swing isn't even worth discussing, as it's a complete pain. The
> application we're building is extremely complex and massive in scale, so
> it can be done. And with Macromedia Flex now available, it's even better.
Didnt I infer flash was better for quicking building simple UI's? The
problem comes when you try to introduce elements of the business logic or
complex processing of things or try to do too much inside the flash, I do
not concider flash a proper enterprise development platform because it is
not possible to fully build a complex enterprise solution solely in flash,
and as already shown has some serious limitions that it simply shouldnt. Its
fine to use flash as part of an enterprise system as you show for the UI
layer (you seem to say you use flash as the interface to your back end Java
app), but any more than that and you are asking for trouble.
> 3) Flash rich clients are faster and smaller than something equivalent
> built with Java.
>
> Here's a comprehensive article on why Flash is better than Swing:
> http://www.softwarereality.com/soapbox/swing.jsp
I didnt say anything about swing and flash?!?!, I know swing is a pain.
Richard
More information about the JDev
mailing list