Do we support both drivers still? I want to use MDB2's matchPattern() function (for case insensitive addresses searching using PostgreSQL) and not sure if I must write equivalent for DB driver. If we're not supporting DB now, the files should be removed from repo.
Do we support both drivers still? I want to use MDB2's matchPattern() function (for case insensitive addresses searching using PostgreSQL) and not sure if I must write equivalent for DB driver. If we're not supporting DB now, the files should be removed from repo.
dont know if ist right in this mail, but we are still using the db backend because auf that bug: http://trac.roundcube.net/ticket/1484880 attachments and includes are limited to 8192bytes when using mdb2 with php greater than 5.1.1 during limitations in userspace stream's.
Stefan _______________________________________________ List info: http://lists.roundcube.net/dev/
Stefan Novak wrote:
dont know if ist right in this mail, but we are still using the db backend because auf that bug: http://trac.roundcube.net/ticket/1484880 attachments and includes are limited to 8192bytes when using mdb2 with php greater than 5.1.1 during limitations in userspace stream's.
Hi, bug has been closed, but I'm not sure if my changes are fixing problem with attachments (i've no such problem with mdb2 driver). Please check r1631.
ps. some fread()'s were replaced with file_get_contents()
A.L.E.C wrote:
Do we support both drivers still? I want to use MDB2's matchPattern() function (for case insensitive addresses searching using PostgreSQL) and not sure if I must write equivalent for DB driver. If we're not supporting DB now, the files should be removed from repo.
I vote for removing the DB classes from the package. But for compatibility reasons we should keep the rcube_db class and make sure that it still implements the same interface as rcube_mdb2. In case of new methods like pattern matching just add an empty method to rcube_db and maybe trigger an error to tell the admins that they should change configuration to mdb2.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
Thomas Bruederli wrote:
I vote for removing the DB classes from the package. But for compatibility reasons we should keep the rcube_db class and make sure that it still implements the same interface as rcube_mdb2. In case of new methods like pattern matching just add an empty method to rcube_db and maybe trigger an error to tell the admins that they should change configuration to mdb2.
I vote for removing 'db_backend' option and everything related to DB.
A.L.E.C wrote:
I vote for removing 'db_backend' option and everything related to DB.
Well, that's another option, right. Any veto out there?
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
Thomas Bruederli wrote:
A.L.E.C wrote:
I vote for removing 'db_backend' option and everything related to DB.
Well, that's another option, right. Any veto out there?
No one? Last chance.
On Tue, Aug 12, 2008 at 10:55 AM, A.L.E.C alec@alec.pl wrote:
Thomas Bruederli wrote:
A.L.E.C wrote:
I vote for removing 'db_backend' option and everything related to DB.
Well, that's another option, right. Any veto out there?
No one? Last chance.
DB is deprecated in favour of MDB2. We should stick to that and get rid off DB.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
Just wondering, why use a DBAL if there is PDO? Native, C based, fast,
clean, standard...
lg, Mike
On Tue, Aug 12, 2008 at 4:46 PM, Michael Baierl mail@mbaierl.com wrote:
Just wondering, why use a DBAL if there is PDO? Native, C based, fast, clean, standard...
It is c-based, but it's not fast and also not very clean. I don't want to start a flamewar, but at least PDO(v1) is just very far away from that. Aside, a DBAL offers more than just the abstraction part - all the helper functions etc..
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On Wed, 6 Aug 2008 10:50:19 +0200, "Stefan Novak" stefan.novak@bnet.at wrote:
Do we support both drivers still?
Yes.
I want to use MDB2's matchPattern() function (for case insensitive addresses searching using PostgreSQL) and not sure if I must write equivalent for DB driver. If we're not supporting DB now, the files should be removed from repo.
dont know if ist right in this mail, but we are still using the db backend because auf that bug: http://trac.roundcube.net/ticket/1484880 attachments and includes are limited to 8192bytes when using mdb2 with php greater than 5.1.1 during limitations in userspace stream's.
Stefan _______________________________________________ List info: http://lists.roundcube.net/dev/
///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! .
List info: http://lists.roundcube.net/dev/
..OOPS...
On Wed, 6 Aug 2008 10:50:19 +0200, "Stefan Novak" stefan.novak@bnet.at wrote:
Do we support both drivers still?
Sorry, I read the question too fast. Let me rephrase my last response.
I believe the DB driver /should/ continue to be supported.
I want to use MDB2's matchPattern() function (for case insensitive addresses searching using PostgreSQL) and not sure if I must write equivalent for DB driver. If we're not supporting DB now, the files should be removed from repo.
dont know if ist right in this mail, but we are still using the db backend because auf that bug: http://trac.roundcube.net/ticket/1484880 attachments and includes are limited to 8192bytes when using mdb2 with php greater than 5.1.1 during limitations in userspace stream's.
Stefan _______________________________________________ List info: http://lists.roundcube.net/dev/
///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! .
List info: http://lists.roundcube.net/dev/
On Tue, Aug 12, 2008 at 7:15 PM, chris# chris#@codewarehouse.net wrote:
..OOPS...
On Wed, 6 Aug 2008 10:50:19 +0200, "Stefan Novak" stefan.novak@bnet.at wrote:
Do we support both drivers still?
Sorry, I read the question too fast. Let me rephrase my last response.
I believe the DB driver /should/ continue to be supported.
http://pear.php.net/package/DB
Any reason why we should support software that is outdated? :)
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On Tue, 12 Aug 2008 19:22:02 -0400, till klimpong@gmail.com wrote:
On Tue, Aug 12, 2008 at 7:15 PM, chris# chris#@codewarehouse.net wrote:
..OOPS...
On Wed, 6 Aug 2008 10:50:19 +0200, "Stefan Novak" stefan.novak@bnet.at
wrote:
Do we support both drivers still?
Sorry, I read the question too fast. Let me rephrase my last response.
I believe the DB driver /should/ continue to be supported.
http://pear.php.net/package/DB
Any reason why we should support software that is outdated? :)
Realizing for a long that "obsolescence is key". Pretty much makes all software "outdated" later than a month, or two. But given that DB, and it's associated drivers are still included in all major "distros" "ports/package" systems. I wonder "whos" driving obsolescence in this case. RC?
On another note, has anyone conclusively confirmed that the (fread | fr)_length issue has disappeared using MDB2 with RC?
Best wishes.
--Chris
Till
///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! .
List info: http://lists.roundcube.net/dev/
On Tue, Aug 12, 2008 at 7:42 PM, chris# chris#@codewarehouse.net wrote:
On Tue, 12 Aug 2008 19:22:02 -0400, till klimpong@gmail.com wrote:
On Tue, Aug 12, 2008 at 7:15 PM, chris# chris#@codewarehouse.net wrote:
..OOPS...
On Wed, 6 Aug 2008 10:50:19 +0200, "Stefan Novak" stefan.novak@bnet.at
wrote:
Do we support both drivers still?
Sorry, I read the question too fast. Let me rephrase my last response.
I believe the DB driver /should/ continue to be supported.
http://pear.php.net/package/DB
Any reason why we should support software that is outdated? :)
Realizing for a long that "obsolescence is key". Pretty much makes all software "outdated" later than a month, or two. But given that DB, and it's associated drivers are still included in all major "distros" "ports/package" systems. I wonder "whos" driving obsolescence in this case. RC?
On another note, has anyone conclusively confirmed that the (fread | fr)_length issue has disappeared using MDB2 with RC?
Software is outdated when updates are available or when they are superceeded by another. I am not talking about running bleeding edge code. MDB2 excels DB in many ways, not just in more recent updates.
Anyway, my vote stands - remove code we don't need. If distros wanna drag DB along it's probably because of dependencies in other software. Let's remove ours and make it easier for them to get rid off it. ;)))
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On Thu, 14 Aug 2008 16:02:25 -0400, till klimpong@gmail.com wrote:
On Tue, Aug 12, 2008 at 7:42 PM, chris# chris#@codewarehouse.net wrote:
On Tue, 12 Aug 2008 19:22:02 -0400, till klimpong@gmail.com wrote:
On Tue, Aug 12, 2008 at 7:15 PM, chris# chris#@codewarehouse.net
wrote:
..OOPS...
On Wed, 6 Aug 2008 10:50:19 +0200, "Stefan Novak"
wrote:
Do we support both drivers still?
Sorry, I read the question too fast. Let me rephrase my last response.
I believe the DB driver /should/ continue to be supported.
http://pear.php.net/package/DB
Any reason why we should support software that is outdated? :)
Realizing for a long that "obsolescence is key". Pretty much makes all
software "outdated"
later than a month, or two. But given that DB, and it's associated
drivers are still included
in all major "distros" "ports/package" systems. I wonder "whos" driving
obsolescence in
this case. RC?
On another note, has anyone conclusively confirmed that the (fread |
fr)_length issue has
disappeared using MDB2 with RC?
Software is outdated when updates are available or when they are superceeded by another. I am not talking about running bleeding edge code. MDB2 excels DB in many ways, not just in more recent updates.
FTR I'm not talking "bleeding edge" either. :)
Anyway, my vote stands - remove code we don't need.
It's your vote, and you have every right. :)
If distros wanna drag DB along it's probably because of dependencies in other software.
Could it not also be that keeping it lends itself to greater flexibility, which, in turn lends itself to easier "adoptability", or ease of use? Point being; if having it means that more people are likely to meet the _prerequisites_, then ppl will be more likely to adopt it. No? Also, really, how much overhead does keeping it really impose?
Let's remove ours and make it easier for them to get rid off it. ;)))
I couldn't help but notice the omission of an answer to the earlier reported issue with MDB2 regarding file reads (attachments). Has anyone yet _conclusively_ determined that the issue no longer exists?
--Chris
Till
///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! .
List info: http://lists.roundcube.net/dev/
On Thu, Aug 14, 2008 at 8:01 PM, chris# chris#@codewarehouse.net wrote:
I couldn't help but notice the omission of an answer to the earlier reported issue with MDB2 regarding file reads (attachments). Has anyone yet _conclusively_ determined that the issue no longer exists?
Sorry about that. :)
Is there a ticket about that which says "fixed"? I could look into that.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On Thu, 14 Aug 2008 17:01:31 -0700, chris# chris#@codewarehouse.NET wrote:
On Thu, 14 Aug 2008 16:02:25 -0400, till klimpong@gmail.com wrote:
Anyway, my vote stands - remove code we don't need.
It's your vote, and you have every right. :)
If distros wanna drag DB along it's probably because of dependencies in other software.
Could it not also be that keeping it lends itself to greater flexibility, which, in turn lends itself to easier "adoptability", or ease of use? Point being; if having it means that more people are likely to meet the _prerequisites_, then ppl will be more likely to adopt it. No? Also, really, how much overhead does keeping it really impose?
I'm astonished. The PEAR::DB developers are telling you to change DB -> MDB2, so why do you think it's a good idea to use DB?
I've used MDB2 for quite some time, and I think is more robust, and will get more features in the near future, something that DB will not.
List info: http://lists.roundcube.net/dev/
On Fri, 15 Aug 2008 11:16:07 -0300, Martín Marqués martin@marquesminen.com.ar wrote:
On Thu, 14 Aug 2008 17:01:31 -0700, chris# chris#@codewarehouse.NET wrote:
On Thu, 14 Aug 2008 16:02:25 -0400, till klimpong@gmail.com wrote:
Anyway, my vote stands - remove code we don't need.
It's your vote, and you have every right. :)
If distros wanna drag DB along it's probably because of dependencies in other software.
Could it not also be that keeping it lends itself to greater
flexibility,
which, in turn lends itself to easier "adoptability", or ease of use? Point being; if having it means that more people are likely to meet the _prerequisites_, then ppl will be more likely to adopt it. No? Also, really, how much overhead does keeping it really impose?
I'm astonished. The PEAR::DB developers are telling you to change DB -> MDB2, so why do you think it's a good idea to use DB?
I've used MDB2 for quite some time, and I think is more robust, and will get more features in the near future, something that DB will not.
Oh. I quite agree that MDB2 is more robust - no doubt about it. I would also assert that many are of the philosophy that "if it ain't broke, don't fix it". Which will greatly account for those that are still using DB. There is still a possible issue with MDB2 regarding file reads (attachments). While this may be a "border case". Until the source of the issue has been _conclusively_ determined (which may in fact turn out to be an MDB2 version) DB should (must?) remain. No?
Best wishes.
--Chris
///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! .
List info: http://lists.roundcube.net/dev/
On Sun, Aug 17, 2008 at 6:26 AM, chris# chris#@codewarehouse.net wrote:
Oh. I quite agree that MDB2 is more robust - no doubt about it. I would also assert that many are of the philosophy that "if it ain't broke, don't fix it". Which will greatly account for those that are still using DB. There is still a possible issue with MDB2 regarding file reads (attachments). While this may be a "border case". Until the source of the issue has been _conclusively_ determined (which may in fact turn out to be an MDB2 version) DB should (must?) remain. No?
Chris,
I still don't understand which issue it is, so can you please point out if an issue has been reported, or not? If it has not been reported, please open a ticket and include steps to reproduce it (e.g. sample email) so we can fix it right away?
Thanks, Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On Sun, 17 Aug 2008 03:26:16 -0700, chris# chris#@codewarehouse.NET wrote:
Oh. I quite agree that MDB2 is more robust - no doubt about it. I would also assert that many are of the philosophy that "if it ain't broke, don't fix it". Which will greatly account for those that are still using DB. There is still a possible issue with MDB2 regarding file reads (attachments). While this may be a "border case". Until the source of the issue has been _conclusively_ determined (which may in fact turn out to be an MDB2 version) DB should (must?) remain. No?
I just noticed that ALEC checked in a change that removed DB yesterday. Did Chris' concerns above get addressed, or is there still a chance that there's a problem with attachments and MDB2?
List info: http://lists.roundcube.net/dev/
Doug Mandell wrote:
I just noticed that ALEC checked in a change that removed DB yesterday. Did Chris' concerns above get addressed, or is there still a chance that there's a problem with attachments and MDB2?
fread() issues requested by Chris have been fixed, so if there's still some problem with attachments should be reported to trac.