So, what's up with Spark? Many of you have commented on the fact that the pace of development has slowed and that Derek is less present in the community. Now that a major new version of SparkWeb is out, it seems like a good time to provide a more detailed status report on everything happening around client development.
First up, an announcement: Derek has taken a new position (Sales Engineer) inside of Jive. So far he seems to be loving it, but I'll let him comment on this blog post with further details. 
Unfortunately, that means that Spark has lost its lead developer. For the time being, other team members have stepped in to help out. We're committed to providing bug fixes and minor new fixes to Spark for the foreseeable future. It remains one of the best cross-platform XMPP clients available.
Since Spark development is slowing down, what's next? Most of Jive's XMPP client efforts are now focused on the web via the SparkWeb Flash client. We're using the same technology base to add real-time features to Clearspace. Further, the upcoming Adobe Air technology offers the intriguing possibility of building a new desktop client using Flash. To us, it all seems like the perfect triple play -- a single code base that can be used for Sparkweb, Clearspace features and a new Spark desktop client. Only Sparkweb is ready so far, but you'll see new real-time features in Clearspace soon and we'll keep everyone updated on a desktop client based on Adobe Air.
Change isn't always easy and I'm sure that some of you will be disappointed to hear that our approach to how we build Spark is changing. There may be some rough spots as we move from one technology to another, but we're pretty excited about where things are headed.
Ignite Realtime Blog
Previous Next
wroot
Oh, well. I hope that new Air technology will be less impacting on pc resources as java is. Btw, what about changing company's name? It's becomming less Javish more and more
So, before switching to new base, can you make current Spark more bug free? Will there be 2.5.8 final? 2.5.x?
I'm starting to think we will never switch to Spark.
wroot
what's this planetjabber tag for? i dont see any connection in internet to it and in this community, seems useless to me.
jadestorm
in response to: wroot
It's an indicator that the post should show up in planet.jabber.org. planet.jabber.org uses an rss feed that looks for that tag explicitly.
wroot
in response to: jadestorm
i see, i wonder how can i found out this blog ID to post link to it in clearspace via { blogpost:id=xxxx }
jadestorm
in response to: wroot
They're all posts from within Clearspace, so you can find the same posts if you go under Community. Of course, you probably already now that, and that said, I have no idea how to find te actual ID number! I can't find any reference to it. If you look at the source of the page there's a couple of numbers, but I'm not certain which is the proper number to reference this post. Sounds like a good request for the Jive Lounge. ;D ;D
sq89
Can you explain why Jive chose to use Adobe's proprietary software instead of Java, which is free/libre software? No hard feelings, but I'm just interested in the advantages that you considered.
wroot
and you will be bundling this adobe air runtime in spark setup or we will have to install it on all computers? i mean will adobe let one to bundle this adobe air.
dawn
in response to: wroot
wroot,
The easiest way to link to this from a discussion or doc within Clearspace is to click on the link icon in the plain text view, browse history (assuming you recently looked at the post or search for it) and insert. It will insert by blogid something like
blogpost:id=1512
This blog post id is 1512.
DavidSmith
in response to: sq89
It hasn't been completely decided yet, but the reason we're leaning this direction is primarily one of unified codebases. Focusing development should let us make the most efficient use of our resources.
Also, quite a bit of the Flash VM is open source now, and will be used in future versions of Mozilla. (not as much as Java, true, but it's still a nice move by Adobe)
AWenckus
in response to: sq89
To add to David's comment, Java on the web is no where near as powerful as what Flash/Flex provide. While Swing and Java has its place currently it is far behind the curve as far as a rich, web based, client experience where Adobe leads the pack. Our motivation is to choose the best technology to do the job to provide the best XMPP client experience for our customers, and currently that choice is the Flash platform.
srt
in response to: AWenckus
I can understand your move to Flash/Flex especially given the poor options Java provides for multimedia integration (even more troublesome when you are on a non-windows platform).
Do you already have an idea of the target platforms? Windows/OSX/Linux for the desktop and web version will probably be easy. A mobile version with the rising number of devices adding support for Flash(Light) would be kinda interesting, too.
What about the license? Will the move to Flex be the end of an activly maintained open source XMPP client from Jive?
DavidSmith
in response to: srt
We're still making plans; SparkWeb is a long way from being able to replace Spark right now, but as we evaluate all the options and figure out our plans things will become clearer.
matt
in response to: srt
srt -- we're still trying to figure out the licensing angle. XIFF is already Open Source and we'll continue to invest in it as the underlying library. We're not planning to try to sell a desktop client... so that leads us towards a path where it would make sense to make the desktop client open source. We still need to sort out how that might impact the real-time work we're doing in Clearspace, however. So, no promises yet but we're definitely trying to think through the issues.
matt
in response to: wroot
wroot -- we'll have a new Spark release out soon and will continue to make as many bug fixes and minor improvements as possible.
sq89
in response to: AWenckus
Thanks for your answers! It sounds like a logical direction indeed to me. Even though I still hope Java will become successful on the web again, I'm sure you're creating a great and flashy XMPP client now. Will it still be mostly enterprise-aimed (like Spark is, as I see it), or can I soon recommend Spark to my friends?
svoisen
This is something I've wanted to do for a while now - create a true XMPP client in AIR - but other work always seems to get in the way. Glad to hear about this new initiative. I think it's a smart move because yes, Java simply can't deliver in the same way (at least without a lot more work involved).
aadaam
AIR isn't mature enough yet, and it won't be for the next 1 or 2 years.
Spark (and Smack) is the only implementation of Jingle code besides the original C++ codebase, it would be a great loss to the XMPP community if you'd discontinue the development even before the standard goes draft, which is very likely unfortunately.
Besides, Smack is a very good quality java codebase, and a lot of internal projects (including mine) are built upon it. Such quality does not exists in the Javascript/flash world, and XIFF is no exception. Loss of spark would mean loss of smack I guess.
If I were you, I'd stick with java for 2008, and wait for a more stable AIR. It contains a lot of bugs yet.
It's obvious that Java retreats to the serverside, mainly web, and it will loose there too, since it has no built-in support for semistructured data like all of its rivals (xml, associative arrays, prototipical inheritance). Java is a classical programming language, and it would have to be on the desktop, like C#.NET or C++.
In my home country, I'm treated as one of the recognizable faces of "Web 2.0", although I was taught to be an enterprise developer, creating information systems in Java and .NET. I know both the java and the javascript (actionscript, ecmascript) world very well.
So, I'd recommend to find someone to replace Derek for one year, finish the work you've done with sparkx.jingle, playing meanwhile with the flash code to see how it fits, and wait for a more stable, much faster AIR Runtime, along with more sophisticated IDE support (although - because of lazy typing - it'd be hard to beat the refactoring tools provided by current Java IDEs - which means slower development cycles, more bugs, less code quality.)
chase@osdev.org
So what does this mean for Smack? Will there be any need to it now that the Spark client will be using XIFF instead? Any chance of getting the Java bits for Smack and Spark released under some additional open source licenses or even released into the public domain once you make the switch to the SparkWeb client? I'm sure some of us would like to continue down the Java path even if Jive goes in a different direction.
jadestorm
in response to: chase@osdev.org
Hi chase (and others). Regarding Smack, I actually use it for the IM Gateway plugin as well, so if nothing else, I still need it. 
hiddenman
1. What about Flash on the x86_64 platform?
2. The same about mobile phones
3. GPL/LGPL
Please, don't throw away Spark, just make it more stable and usable.
Flash eats our CPU resources, crashes our browsers. What does it give us?
wroot
in response to: hiddenman
aelix
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.
jadestorm
in response to: aelix
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.
aelix
in response to: jadestorm
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.
DavidSmith
in response to: aelix
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).
it2000
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).
aadaam
in response to: DavidSmith
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.
DavidSmith
in response to: aadaam
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 )
svoisen
in response to: aadaam
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.
DavidSmith
in response to: svoisen
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.
svoisen
in response to: DavidSmith
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.
aadaam
in response to: svoisen
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 :))
DavidSmith
in response to: aadaam
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.
aadaam
in response to: DavidSmith
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.
http://jsdl.sourceforge.net/
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)
svoisen
in response to: DavidSmith
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.
ibradshaw
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:
1) 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.
2) 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).
3) 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.
4) 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.
5) 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.
6) 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.
7) 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.
wroot
in response to: ibradshaw
It will need AUR player or AUR VM, not ordinar flash player i think. And i hope it could be bundled.
mtstravel
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.
matt
in response to: mtstravel
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
mtstravel
in response to: 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).
winagain
2 or 3 year ago , we need to deploy jabber on a few company , we've spend a lot of time to test different clients in details , finally , PANDION is absolutely the best choice , it's good because it's fast & small (CPU & memory) , very stable (98 - vista , almost never hang or crash !!) , currently , I've almost 200 computers running PANDION.
Moreover , i've a few modifications to the PANDION's HTML files , it give me good result , and i've create a small plugin for internal use too.
the most disappointed point is the development of PANDION is very slow (last version was Jan 2006) and I'm wondering if the JIVE team will have a look to PANDION.
my years of software development experiment tell me that developing windows client application in JAVA is just like a put a flower in girl's hair , it look nice and the application can sell at much higher price , but , finally , it's bad choice.
Ignite Realtime Blog
Ignite Realtime Blog- Contributors:
-
srt
-
svoisen
-
ryang
-
barata7
-
jadestorm
-
dele
-
AWenckus
-
DavidSmith
-
flashgrand
-
greg
-
dombiak_gaston
-
ddman
-
dawn
-
matt
-
admin
cool
very nice !!, i am already implements our client for Adobe AIR .