Comments on: Introducing POCO Data http://pocoproject.org/blog/?p=24 News and discussion for the POCO Community Thu, 09 May 2013 12:05:16 +0200 http://wordpress.org/?v=2.8.5 hourly 1 By: alex http://pocoproject.org/blog/?p=24&cpage=1#comment-79 alex Tue, 26 Sep 2006 10:11:35 +0000 http://appinf.com/poco/blog/?p=24#comment-79 I don't see how wrapping SOCI would enhance adoption of Poco either. Poco can already integrate nicely with Boost. For example, Peter's reply to my query about tuples explains how: [quote] Well, Poco::Tuple is currently not planned, but it should be possible to use boost::tuple in PocoData by providing the necessary TypeHandler template specializations. [end quote] However, I'd have to have a good reason to couple myself with another library. Generally speaking, tight coupling (and dependencies in general) are bad. Same is probably SOCI's developer's concern when considering a 'merger' with anyone. At any rate, I think we are beating a dead horse here. Alex I don’t see how wrapping SOCI would enhance adoption of Poco either. Poco can already integrate nicely with Boost. For example, Peter’s reply to my query about tuples explains how:
[quote]
Well, Poco::Tuple is currently not planned, but it should be possible to use boost::tuple in PocoData by providing the necessary TypeHandler template specializations.
[end quote]
However, I’d have to have a good reason to couple myself with another library. Generally speaking, tight coupling (and dependencies in general) are bad. Same is probably SOCI’s developer’s concern when considering a ‘merger’ with anyone. At any rate, I think we are beating a dead horse here.

Alex

]]> By: Cornell http://pocoproject.org/blog/?p=24&cpage=1#comment-78 Cornell Mon, 25 Sep 2006 19:57:04 +0000 http://appinf.com/poco/blog/?p=24#comment-78 Enhance adoption would have been a better term. Boost libraries have a growing mindshare, although I myself am not a fan of their extreme emphasis on templates. Boost based code takes forever to compile.. However, if Poco can integrate nicely with Boost it sure would help speed up adoption among Boost fans. A wrapper on top of wrappers sounds convuluted I agree but you take advantage of the work done by potentially hundreds of other developers while concentrating on other parts of Poco. c Enhance adoption would have been a better term. Boost libraries have a growing mindshare, although I myself am not a fan of their extreme emphasis on templates. Boost based code takes forever to compile..
However, if Poco can integrate nicely with Boost it sure would help speed up adoption among Boost fans.
A wrapper on top of wrappers sounds convuluted I agree but you take advantage of the work done by potentially hundreds of other developers while concentrating on other parts of Poco.

c

]]> By: alex http://pocoproject.org/blog/?p=24&cpage=1#comment-77 alex Mon, 25 Sep 2006 16:29:20 +0000 http://appinf.com/poco/blog/?p=24#comment-77 I'm not sure I understand how SOCI boostification would enhance usability of Poco. And wrapping a wrapper which wrapps other wrappers sounds like a bit too much wrapping. Alex I’m not sure I understand how SOCI boostification would enhance usability of Poco. And wrapping a wrapper which wrapps other wrappers sounds like a bit too much wrapping.

Alex

]]> By: Cornell http://pocoproject.org/blog/?p=24&cpage=1#comment-76 Cornell Mon, 25 Sep 2006 12:44:54 +0000 http://appinf.com/poco/blog/?p=24#comment-76 How about designing PocoData simply as warapper around SOCI. This would enhance the usability of Poco if SOCI ever gets accepted into Boost. c. How about designing PocoData simply as warapper around SOCI. This would enhance the usability of Poco if SOCI ever gets accepted into Boost.

c.

]]> By: alex http://pocoproject.org/blog/?p=24&cpage=1#comment-75 alex Mon, 25 Sep 2006 10:48:51 +0000 http://appinf.com/poco/blog/?p=24#comment-75 One way or the other, there are two parallel very similar implementations. It is sad that this is the case because way more could be achieved if the two teams joined the eforts. I have invited SOCI folks to join the Poco community and effort but they declined it. So, for the time being, the efforts shall continue in parallel. Alex One way or the other, there are two parallel very similar implementations. It is sad that this is the case because way more could be achieved if the two teams joined the eforts. I have invited SOCI folks to join the Poco community and effort but they declined it. So, for the time being, the efforts shall continue in parallel.

Alex

]]> By: pschojer http://pocoproject.org/blog/?p=24&cpage=1#comment-74 pschojer Fri, 22 Sep 2006 07:14:12 +0000 http://appinf.com/poco/blog/?p=24#comment-74 Well, I have to object. PocoData is NOT a port of SOCI. We took the SOCI library as inspiration source, and redesigned and implemented it from scratch. SOCI has a very good interface, so there was no need to reinvent it. We simply changed the parts where we felt it improves the usage of PocoData. About contributing to SOCI: too much work. With our interface changes most parts of SOCI would have been in need of a rewrite, probably the same is true for their connector implementations. Add to that the time effort to understand their code, to communicate changes... Way faster to start from scratch :-) br Peter Well,
I have to object.
PocoData is NOT a port of SOCI. We took the SOCI library as inspiration source, and redesigned and implemented it from scratch. SOCI has a very good interface, so there was no need to reinvent it. We simply changed the parts where we felt it improves the usage of PocoData.
About contributing to SOCI: too much work. With our interface changes most parts of SOCI would have been in need of a rewrite, probably the same is true for their connector implementations. Add to that the time effort to understand
their code, to communicate changes…
Way faster to start from scratch :-)
br
Peter

]]> By: Vlad http://pocoproject.org/blog/?p=24&cpage=1#comment-73 Vlad Fri, 22 Sep 2006 04:02:23 +0000 http://appinf.com/poco/blog/?p=24#comment-73 This implementation seems to me to be a port of SOCI to Poco. If the intent is to mimic SOCI why not simply contribute to the SOCI project. I am sure they could use your help. The thing is C++ desperately needs a standard RDBMS access library. It appears SOCI aims to achieve this. But am not sure they have what it takes to implement a trully industrial strength library. Right now I am using OTL together with Poco because I don't think SOCI is there yet. OTL is more complete and mature but SOCI seems better architected so it is likely to succeed. I was looking foward to the promised Poco data but if the goal is to re-do SOCI I might as weel wait for SOCI to mature. May be I am pre-judging here Poco::data but am kind of library junky so I will give a it fare try.. v. This implementation seems to me to be a port of SOCI to Poco. If the intent is to mimic SOCI why not simply contribute to the SOCI project. I am sure they could use your help. The thing is C++ desperately needs a standard RDBMS access library. It appears SOCI aims to achieve this. But am not sure they have what it takes to implement a trully industrial strength library.
Right now I am using OTL together with Poco because I don’t think SOCI is there yet. OTL is more complete and mature but SOCI seems better architected so it is likely to succeed. I was looking foward to the promised Poco data but if the goal is to re-do SOCI I might as weel wait for SOCI to mature.
May be I am pre-judging here Poco::data but am kind of library junky so I will give a it fare try..

v.

]]>