On 20 December 2011 14:07, Gary Gregory <garydgreg...@gmail.com> wrote: > On Dec 20, 2011, at 2:02, Damjan Jovanovic <damjan....@gmail.com> wrote: > >> On Mon, Dec 19, 2011 at 9:33 PM, Gary Lucas <gwlu...@sonalysts.com> wrote: >> >>> I see there's some discussion about the next release of Sanselan between >>> Damjan Jovanovic, Gary Gregory (I'm the other Gary) and some of the Apache >>> community leaders. My name was even mentioned... so I thought I'd chime in. >>> >>> First off, Damjan posted a note to the issue tracker that my submitted >>> patches for performance enhancements aren't going to make it into the 1.0 >>> release. While I'm naturally disappointed about that, I can understand the >>> perspective that it is probably the best choice at this time. Also, a delay >>> would give us more time to refine the concept before we start applying it >>> to other areas of the code. The only point I would add here is that I >>> think Sanselan does have problems with performance and that those problems >>> are really unnecessary. Java is plenty fast nowadays and there's nothing >>> wrong with the Sanselan code per se, just a rather an unlucky choice on >>> which API element to use for setting pixel values in an image. I think >>> that the kind of changes proposed for one small area of the code base (TIFF >>> images) would have applicability to other parts of the code. I also think >>> that performance is probably one of the issues might keep Sanselan from >>> reaching a broader user base. So I'd encourage everyone interested in >>> Sanselan development to keep that in mind for future releases. >>> >> >> No, I never said your patches wouldn't make it into the 1.0 release. I said >> they wouldn't make it into the "next" release, which at the time I was >> thinking would be 0.98, and would be released within days. Things have >> changed since then, the next release will be 1.0, and it's due later, so >> maybe your patches will make it. >> >> Also I care very much about performance - in fact right now I am optimizing >> my TIFF CCITT T.4 and T.6 compression algorithms that I will commit later - >> but premature optimization is said to be the root of all evil, and the >> state of Sanselan's TIFF parser strikes me as very premature (eg. TIFF is >> fundamentally a multi-image file format, but there was no support for >> reading multiple images from TIFF files until my patch yesterday). >> >> In terms of renaming the project from "Sanselan" to "Image" or something >>> like that. Well, I think the key issue here is that the change in name >>> would signal a much more ambitious concept of what the project is for. To >>> me, the name Sanselan says "I'm a small and unassuming software package >>> focused on a particular niche application." The name "Image" or something >>> like that says "I'm gunning for the JAI, and it's high time somebody did it >>> too". I wonder if the reason that the original authors chose the obscure >>> name was that their intentions were fairly modest, though with the amount >>> of work that went into Sanselan it seems a shame not to promote it. So >>> I'm strictly on the fence about the whole name change thing. >>> >>> >> Sanselan seems to have started as an image metadata extraction/manipulation >> project. For example the TIFF image support is flaky, but the parts of TIFF >> used for JPEG EXIF metadata are excellent. >> >> >>> Finally, I wanted to ask if there would be any problems in changing the >>> compiler targets in the pom.xml to 1.5 for release 1.0. The current >>> compiler targets are set up to compile with Java 1.4 features, but I just >>> switched them to 1.5 and everything build and tested without errors. I'm >>> not proposing that anyone go make code changes to Sanselan so that it uses >>> generics or other 1.5 fixtures. Just compile the current code to >>> accommodate 1.5 rather than being stuck in the 1.4 feature set. By >>> switching release 1.0 to Java 1.5 does have the advantage that in any new >>> work, coders will be able to use 1.5 without compatibility issues. >>> >>> >> I was hoping for several small releases with incremental changes, but since >> we seem to be going the route of a big bang release with many changes, we >> might as well do the 1.5 upgrade too. > > I like release early release often. My intent is to not have big bang > releases.
Release early, release often is fine so long as that does not mean frequent compatibility breaks. It can be tricky to get an API right; releasing early can make it more likely that the API will need to be changed later. > If someone wants to push a 0.x release now, please do so. -1 That would be contrary to the Commons versioning rules - a package name change requires a major version bump. > For 1.0, we should make all big changes before 1.0, which may feel > like a big bang release. Anything that breaks compatibility should be > done now before a 1.0. Agreed. > Using java 5 can break source compat once add generics, so you only > want to do that when you have to. If the java 5 changes are not user > visible like using enhanced for loops the you can do it anytime. Someone else suggested updating source and target version to 1.5, but not adding generics. I think the idea was to allow Java 5 methods such as StringBuilder etc. However AFAIK this will result in huge numbers of compiler warnings. Since Apache releases source, IMO we should at least ensure that the source compiles cleanly. So I am -1 on changing the source requirements without fixing generics. > But, if someone wants to put the time in now, go for it! :) > Performance improvements can come in after for example but I'll let > someone else make that call. > > Now is the time to get the API right. Indeed. > Gary >> >> >>> Gary >>> >>> >>> >>> >>> Computer Programming is the Art of the Possible >>> Gary W. Lucas >>> Sonalysts, Inc. >>> 215 Parkway North >>> Waterford, CT 06385 >>> >> >> >> Damjan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
