After a recent chat with Simon Meier, we decided that I would take over the maintenance of the exceedingly popular
Of course, this package has been largely superseded by the new builder shipped inside
bytestring itself. The point of this new release is to offer a smooth migration path from the old to the new.
If you have a package that only uses the public interface of the old
blaze-builder, all you should have to do is compile it against
blaze-builder-0.4 and you will in fact be using the new builder. If your program fails to compile against the old public interface, or there’s any change in the semantics of your program, then please file a bug against my
If you are looking for a function to convert
Data.ByteString.Builder.Builder or back, it is
id. These two types are exactly the same, as the former is just a re-export of the latter. Thus inter-operation between code that uses the old interface and the new should be efficient and painless.
The one caveat is that the old implementation has all but disappeared, and programs and libraries that touch the old internal modules will need to be updated.
This compatibility shim is especially important for those libraries that have the old blaze-builder as part of their public interface, as now you can move to the new builder without breaking your interface.
There are a few things to consider in order to make this transition as painless as possible, however: libraries that touch the old internals should probably move to the new bytestring builder as soon as possible, while those libraries who depend only on the public interface should probably hold off for a bit and continue to use this shim.
blaze-builder is part of the public interface of both the Snap Framework and
postgresql-simple. Snap touches the old internals, while
postgresql-simple uses only the public interface. Both libraries are commonly used together in the same projects.
There would be some benefit to
postgresql-simple to move to the new interface. However, let’s consider the hypothetical situation where
postgresql-simple has transitioned, and Snap has not. This would cause problems for any project that 1.) depends on this compatibility shim for interacting with
postgresql-simple, and 2.) uses Snap.
Any such project would have to put off upgrading
postgresql-simple until Snap is updated, or interact with
postgresql-simple through the new bytestring builder interface and continue to use the old
blaze-builder interface for Snap. The latter option could range from anywhere from trivial to extremely painful, depending on how entangled the usage of Builders are between
postgresql-simple and Snap.
By comparison, as long as
postgresql-simple continues to use the public
blaze-builder interface, it can easily use either the old or new implementation. If
postgresql-simple holds off until after Snap makes the transition, then there’s little opportunity for these sorts of problems to arise.