POCO vs. Boost

[alex]

I think there are two different types of C++ libraries.

(1) Libraries that abstract a specific feature away. ie XML, SQL, HTTP etc.

(2) Libraries that abstract programming concepts away. Containers, Algorithms, Flow control, Design patterns.

Poco is very good at (1) and very poor at (2) that is why I use both boost and Poco together.

As I said, I do not argue that POCO is better than Boost (or the other way around) because they are different and each has it's strong and weak sides - that's why many people use them together. However, I'm not quite sure why you qualify POCO as "very poor" in design patterns.

[guenter]

As Alex said, merging POCO into Boost is very unlikely to happen. The culture clash is just too big, IMO. What we plan though, is to make it easier to use POCO together with Boost (or other libraries, for that matter). One of the plans for 2.0 is to drop our own SharedPtr, and replace it with std::shared_ptr, which, at some point in the next 10 years, will hopefully be widely available

[jmansion]

I don't think a merger is required, but Boost has more mindshare.

I really think you (I'd say 'we', but it doesn't work like that, which is why you're not getting many contributions) should seriously consider realigning for v2 to require Boost, and to drop everything that has functional equivalence in Boost - and just use the Boost stuff.

The same thing needs to happen for the embedded copies of zlib, pcre and so on.

I personally prefer most of the Foundation components where there is overlap, but reality says I'm effectively forced to use Boost and POCO is a luxury. The overlap is annoying and in the case of intrusive_ptr somewhat dangerous.

I know there is a cast-iron case not to make breaking changes in 1.x and that you have existing customers to support with that codebase.

I also perceive that 2.x is to be a breaking change, but I don't get a feeling that we're really talking about a project that will align itself to a community-driven model, or one that isn't shackled by backwards compatibility with your commercial interests. I can't really complain since I can take it or leave it or fork it and you guys are the donors - but I think you may continue to be disappointed by the level of external contribution.

So please let's consider:
- use Boost, not just coexist
- drop Foundation elements that overlap with Boost
- drop embedded copies of third party code (provide a way to build against a provided external snapshot if you want to sort out the
- do the refactoring and redesign to handle IO with better abstraction
- change the documentation markup to the one everyone else uses
- let more experimental code into mainline
- change the build system to one that works across WIndows and POSIX

Its necessary to decide whether 2.0 is an incremental change, or a more radical restart, and how much backwards compatibility is necessary until 2.x has been round the block a few times.

I don't know how many people will contribute to fund 'business as usual'.

[chrisjones]

use Boost, not just coexist

I really hope you don't do this. I really don't like boost, mainly due to it's size and a hassle to build. I like the fact that you can just download Poco and build it, it makes life a lot easier.

change the documentation markup to the one everyone else uses

This is the one single thing i do agree with. Do you use visual studio? Because the comments that are automatically displayed when hovering over symbols are almost always wrong because it takes the comments from above the line rather than below.

change the build system to one that works across WIndows and POSIX

I think supporting a build system such as CMake is good but i don't think the specific project files for different platforms should be removed. As i said before, i like being able to download Poco and just build it. CMake etc. is just another hassle.

[alex]

Broadly speaking, we are opened to optional dependencies to both external libraries and advanced/portable build systems (in fact, CMake is already supported to a great extent). But the keyword here is optional. Anything else would break one of the fundamental goals of the project - minimize dependencies (i.e. "download, build and go" way of doing things) as well as introduced additional maintenance and support hassles (e.g. testing against multiple versions of libraries on different platforms).

Regarding boost, many users who have a need for it are using it together alongside POCO. That is perfectly understandable. While I have a lot of respect for both the project and the mind share behind it, my opinion is that adding dependency on boost would be detrimental to POCO.

Experimental code is more than welcome. Whoever wants to submit experiments in the sandbox is welcome to do so. I would also encourage a whole experimental branch (or call it 'fork', with releases and all) if anyone would have an inclination and time to maintain it. Currently, the trunk is essentially playing that role - I know that some folks (beside myself) are using it.

As for IO, yes some significant work is needed there, async IO in particular - we are behind times with it. The usual 'lack of resources' fuss applies.