Flash eats our CPU resources, crashes our browsers. What does it give us?
Java works very differently?
Honestly I wish this whole single-cross-platform client strategy was abandoned. You either end up with something that eats an enormous amount of memory (Java) or something buggy and full of glitches (flash). All of my users have switched to using their own native client (Pandion & Trillian or Adium) because of complaints about the memory usage of Spark, or just a general disdain for Java in particular.
In my mind the perfect client setup would bet a .NET one for Windows, a Cocoa one for Mac OS, and a GTK one for Linux. I know thats dreaming though.
But there’s plenty of those already available. Cross platform is kind of lacking on the XMPP client front. One can always use their own standalone clients and there’s nothing wrong with that! iChat, Pandion, Trillian, Adium, Gaim … nothing really wrong with any of them! It’s nice to have something though that’s a similar experience across all platforms. That’s actually what I like about Spark. Dancing between OSs and having more or less the same experience.
Yes but the problem is, they all look and act different, and support different features. Which is a nightmare from an enterprise support perspective. They are also targeted towards end-users – not the enterprise.
I guess I’d like to see the features of Spark (SSO, single look and feel, branding, enterprise focus) in a native client.
In a perfect world, I’d absolutely agree. Unfortunately, developing one client (and giving it away!) is already a significant resource investment; developing four (3 native, 1 web) would be quite impractical.
To give you an idea of the effort involved, consider that Adium (which builds on a cross-platform library written by others) has more than 200,000 lines of non-crossplatform code, contributed by 55 different people in 21,551 separate commits, and yet it still has areas where it could improve an enormous amount (multi-user chat support and audio/video chat come to mind).
I hope that this change allows more users to contribute code to Spark. I guess there are some coders who would like an open svn access to the Spark repository or to a new OpenSpark repository (which one could create).
David, I understand that it’s a resource-investment, a price. But it’s not an outhtrown price as you would think.
What Jive must consider is that it works for the enterprise market. And the enterprise world is built upon Java and .NET, not flash. Therefore most enterprise programmers know how to build a java program, but do not know flash, nor it has a good reputation when it comes to stability, scalability, etc.
When someone wants to add a custom process for their jive-based communication system (clearspace, openfire, spark), like supporting some special business process, or kind of communication (sending plans for waterpipes, anything not usual), then he could connect it with their already java-based operational system easily.
When I had to write bots, I’ve written them in Smack, because Java is a usual language for me as an enterprise information engineer. I may speak it better than English And there’s a good IDE support for it.
You cannot provide as strong IDE support for flash as IntelliJ IDEA supports java, because of loosened language constraint. This means effectively no refactoring tools; less design patterns, therefore less testing patterns, less tests, slower development, everything related to code quality becomes weaker.
And this where engineering comes in. Adium is a community project (not mentioning the weak Xcode IDE), with a lot of non-engineers involved. And it’s an online communicated project, therefore common knowledge is weak.
Jive software was built from the engineering knowledge of its founders, and looking at the Spark, Smack, or Openfire code, they’re one of the best engineers I know of. Trust me I have seen a lot of them.
So, you say you win resources with maintaining a single codebase, yup? Let’s see what you loose:
-
all of your company knowledge on Java
-
all of JetBrains’ knowledge on java code and metamodels (basically all IDE support except syntax highlight)
-
some of the “compatibility of knowledge” between you and the companies deploying Spark with a set of other java-based enterprise systems
-
the stability, maturity (and probably authority) of java desktop (remember I stated AIR isn’t mature enough?)
-
all in all, CODE QUALITY.
So, while you may see it as a clear win, I state that java is worth the price, and you shouldn’t hurry into AIR platform yet.
Adam: the comment you’re replying to was discussing why resources prohibit developing native (Cocoa/.NET/GTK/Qt) clients, not a Java one. Spark isn’t going away in the near future (not only is AIR not mature enough, SparkWeb itself isn’t mature enough).
SparkWeb is needed regardless of whether AIR ends up being a viable platform, though, due to the sad state of Java on the web. So I’ll keep improving it, and future plans will develop as the situation becomes clearer.
(and yes, I’m well aware of how amazing my coworkers are )
Adam … Have you actually developed in Actionscript 3? Have you used Eclipse with the FlexBuilder plug-in? There are indeed refactoring tools built into the IDE. Furthermore, AS3 is syntactically so close to Java, that many Java developers I know have been able to pick it up in a matter of hours. The only thing new to a Java developer is the Flex framework, which is thoroughly documented and well-supported by the IDE to the standard expected by any enterprise developer (code hinting, refactoring, code navigation hyperlinking, etc). The language is hardly any looser than Java (strict typing, interfaces, public/private/protected accessors), and design pattern implementations do exist (Cairngorm and other MVC frameworks) with new ones popping up all the time.
I disagree that code quality suffers by moving to AS3, assuming the same caliber of developers However, I will concede that AIR is not nearly as mature as the Java runtime and is susceptible to bugs (from the runtime). This is independent of the code quality of Spark, however.
Sean: One thing I find is that a lot of Java developers are deceived by the syntactic similarity. Yes, you can use Actionscript as a Java-alike, but you lose a lot of its power (hooray for closures!).
Also I’m going to have to disagree with you on Flex Builder. It’s coming along, but it’s no IDEA yet. Refactoring is limited (although it should be very possible for Adobe to expand it in the future), and there are a number of annoying bugs.
Well, I concede that I’ve never used IDEA, only Eclipse. And the latest FlexBuilder betas are buggy as far as stability is concerned (they ****
are
beta though). But I really don’t think that this interferes with one’s ability to write quality code.
And yes, closures are fantastic.
One thing Adam has a valid point on is extending the AS3 code for enterprise-specific functionality. If you want to use Java, your options are very limited. Currently your only hope is Artemis: http://artemis.effectiveui.com/ And this isn’t even close to enterprise-ready. And you’d still need to know AS3.
AS3 is an ecmascript-variant in my knowledge, and I do most of my developments in javascript (dojo, prototype, and our own yui-like but pre-yui class library). I did some play multiple times through the years with openlaszlo, flash mx 2004 and red5, but never used them in production systems. I’ve seen the new XIFF code in SVN, but it was largely javascript-like.
The lambda operators and prototypical inheritance gives us a lot of freedom, and expressiveness, yet we don’t have strong metamodels on them yet - although there exists some design pattenrs, artifical knowledge on the language - to be able to refactor, hint, creating automated tests, code coverage, etc - is weak.
I have installed the new flexbuilder plugin for eclipse, the only refactoring tool it provided was rename, which is, let’s say, an important, albeit not the most difficult one. Did I do something wrong?
I have also seen the demos of javascript/actionscript refactoring in idea (http://www.jetbrains.com/idea/features/javascript_editor.html#link3), let’s say, it provides much more on java.
(Haven’t changed to 7.x yet, although I have a license, don’t break what works
David: it’s OK that web is the most important platform today, yet for example the voice support of spark isn’t finished yet, and it has some potential still, so it’s not that you shouldn’t abandon it, but you could improve it - and that was my original pont.
Perhaps if you would build a metamodel (flex code generation?) then you could provide both platforms with the same abilities, at least in some areas. Personally I would really like to see a visual XEP-developer tool which could generate spark plugin as well as a sparkweb flash build )
Adam: One of the main issues with Spark voice support is that JMF is a dead project, but we’ve been unable to find anything better for Java at the moment.
ActionScript/ES4 should be much easier to refactor than Javascript, due to the static typing. I’ll be interested to see what they manage to get working though.
QuickTime for Java?
I understand that there’s no linux support for it. Probably you could build a native java library (or what are C-java bindings called in IDEA) on top of some common audio system like Jack audio, NAS, or probably better, SDL.
Have you looked at that?
Or just extract an interface which is quicktime-like, and find a native library - esd for gnome, arts for kde - on linux, which you somehow create the decorator classes.
(Srry, I know it was a bit offtopic, but I hope both Jive and the jabber community would benefit from such)
I once worked on an enterprise project in Actionscript 1 and Java remoting. Needless to say, it was quite a disaster. Still, even then we had automated unit testing using ASUnit and Ant. You can do automated testing in AS3. But given the inherent flexibility of the language, it may not be what you’re looking for.
The XIFF 3 code is a direct port from the AS2 version. Basically, it was modified so that it would compile as AS3. That’s it. In a perfect world it would be re-written to make better use of AS3 and E4X. But I don’t live in a perfect world And either way, it’s still going to look like Javascript.
I will check out the IDEA JS/AS code refactoring. Renaming, moving and deleting files/vars/methods/classes is all I’ve ever needed of refactoring though. The extra refactoring options in IDEA, like extract method, I would probably use, but they wouldn’t be a selling point for me personally.
Just to give my pennies worth…
As someone who has to look after this stuff when its deployed (rather than having to develop any of it) there are a couple of things, and it doesnt matter what development platform:
-
It HAS to be cross platform. This is the thing that makes spark so viable. One client, one set of instructions, one way of doing things be it on win, mac or linux - easy to keep common versions via spark manager.
-
It has to be a client app. Web based things are ok for occasional use, but no good for every day use. (I may have misinterpreted, but looks like its going web way rather than application way).
-
Spark is what makes openfire stand out. Its an entire solution packaged up, from server to client. Theres lots of openfire type servers and lots of spark type clients, but none from one place.
-
RAM is cheap. Who cares if it uses 50Mb. I need that to start outlook. Not like 5 years ago and it would cripple you.
-
Write in what you have developers for. Doesnt really matter if its Java or something else as long as it works and progress doesnt stop while everyone learns something new, with the associated useless releases as there full of bugs for 6 months or so. Webchat was buggy to say the least when it started out… deploying desktop apps with bugs isn’t nice… web apps can be sorted easily, desktop ones can’t.
-
Dont make it dependent on other things, like having flash installed on your pc that involves a dual installation. Not sure if it can be bundled or not like java is with the install.
-
If 6 isnt followed then there may be issues with flash versions? Don’t know the answer, just a thought.
Just my pennies worth from a non-programming perspective.
…there may be issues with flash versions?..
It will need AUR player or AUR VM, not ordinar flash player i think. And i hope it could be bundled.
It has been my observation for a while that spark has become the bastard step child of the company. That is unfortunate as it is very well suited for the business world in which I have deployed it. We need the seamless integration into the features of Openfire. We want to restrict what people can do during work time. i think you are doing the community a great disservice by relgating Spark in its current format to a back burner or side project status. I realize there is not a profit in spark but you must see the value in maintaining a product that is designed to work with your server. For all the power of your server means nothing if I don’t have a client to use with it. Oh I know there are other clients, but most windows variants are junk. I realize I am not a key contributor or a staff member, but I have contributed greatly to the community by providing support for your products. I try to help Daniel as best I can with debugging and testing as well. I would love to contribute more but have not done any coding in more than 12 years. I will continue to support your products as best I can, but I must stress that you must not let spark just wither away. I realize negative comments in the community do not inspire contunued development, but remember even negative feedback comes from a user of your product. And there are probably many more users you never hear from because they are satified with the product.
Todd,
Thanks for your feedback. It’s definitely not our intention to leave any users out in the cold. We love Spark too, and we’re not going to transition until there’s a really solid alternative. We’ll definitely keep posting details with our progress.
Regards,
Matt
I am worried less about the transition as the continued development of Spark. It is the product we chose to standardize our company on. Our staff has fully embraced the product to the point that send an IM is now referred to Sparking somebody. I can not impress upon you enough that you must continue to support this product with active development (bug fixes and regular updates).