August 30, 2009
We (Xuggle) are nailing down our development plan for the rest of the year, and wanted to get your input on what’s most important to you. We have a lot of great stuff under development, but want to make sure we’re putting the right priority on the right features. So we’ve put together a very brief (1 page) survey:
Please fill it out for us — we’ll use your input to help guide what new features and products we ship over the next year. If you could give us your input by end of next week, that’d be super awesome!
Thanks in advance,
– Art & Robert
August 26, 2009
We made a minor change today to Xuggler. As far as we know, it doesn’t impact any existing users but we wanted to give a shout out to let people know: We’re no longer supporting using Xuggler via the C++ API, and we no longer allow commercial users to integrate with Xuggler via C++.
Why is this? Because we’ve found that (a) maintaining C++ backwards compatibility between releases is getting to be very restrictive, (b) 100% of our users and customers to-date (that we know of) have been using only Java to access Xuggler and (c) the current Windows binaries are built with G++ and we’ve had a lot of queries from people wanting to use MSVC++ instead (which we don’t use today).
By dropping official C++ API support the Xuggler project gets the following benefits:
- We can start to introduce exception throwing into the API now that we’re targeting primarily Java. C++ exception support across compilers is spotty (e.g. throwing exceptions across DLL boundaries on GCC under windows causes a crash) and was part of the reason we avoided them.
- We can make intelligent decisions about where to implement functionality; before today we tried really hard to add methods in both the Java API and the C++ API but frankly, some methods make more sense to add in Java code, whereas others make more sense to add in C++. A good example is the IStreamCoder#getExtraData() method we added today — it makes more sense to implement that method in Java, whereas the lower-level “copy into buffers” methods makes more sense in C++.
- We can break the binary C++ API and ABI across releases when it makes sense. Today we can’t change the order we declare methods in a C++ interface for fear that some other (non-Xuggle) person is using the API via C++. We can’t add data elements to a C++ class that’s part of the ABI. By removing this support, we can re-order methods, add data, and do whatever we need to more efficiently serve the Java API. Sine the Java JNI interface dynamically queries shared objects for functions, it doesn’t care about method order.
- We’re not giving false hopes to Windows developers that they can use Xuggler from C++ in their .NET applications, which helps lower some of our support costs.
Xuggler will continue to be implemented in C++, C, Assembly and Java — we’re just stopping claiming to support a C++ interface that no one is using, and is holding us back. AGPL users are free to build on the C++ API, but be aware we’re absolutely not going to support it or attempt to maintain compatibility on that interface between releases. We may at some point in the future introduce a C++ API that is supportable for us (and hopefully works with MSVC++), but that’s in the future.
Let me know if you have any questions, or you were using the C++ API and we weren’t aware.
August 24, 2009
On an unrelated note, I’ve put a little project SarynPaint up on google code. SarynPaint a simple paint program I made a few years back for my friend Saryn. She was two years old at the time and couldn’t click and drag the mouse, but liked to play on the computer. It has three mousing modes for progressively older children. Both a jar file and a disk image containing a Mac application are available. Have fun!
August 19, 2009
We just shipped Xuggler 3.2, code named “Dalton”. Check it out here.
Dalton was all about performance improvement tweaks for us. Xuggler is now even faster, uses less memory, and is easier to use raw-data with that ever before. Plus, the very latest FFmpeg, as always, is included, complete with Windows, Mac and Linux installers.
The plan from here is somewhat secret, but you’ll see some big updates from us in the next few months. Stay tuned.
– Art & Robert
August 11, 2009
Quick update: Turns out that Apple’s java implementation of webapps can only support Java 1.5, so for now, we’re going to keep supporting 1.5 at least through the 3.x series of Xuggler releases.
For our next release (3.2) we plan to remove Java 1.5 support. As far as we know from the people we’ve worked closely with, no one is actually using Java 1.5. But if you, please let us know by end of this week so we can figure out if we need to revisit this.
Why are we removing Java 1.5 support?
- Sun is deprecating support for Java 1.5 in 3 months.
- There are some Java 1.6 optimizations we’d like to take advantage of in Xuggler that we can’t today.
August 10, 2009
It’s been about a month since our 3.1 release and some folks are probably wondering what’s up. Well, we continue to work on Xuggler (the tip of tree includes new features such a 10% performance improvement for multi-threaded servers when allocating memory), but we’ve also been hard at work on another project that we can’t say much about yet. But stay tuned — Robert and I are pretty excited about it, and we think you will be too.
We continue to be available for questions and support for Xuggler. Please join the xuggler-users group if you’re running into trouble. And if you’re a commercial customer, don’t worry, you always take priority!