> 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 _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
