www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The end of curl (in phobos)

reply Robert burner Schadek <rburners gmail.com> writes:
As discussed yesterday at DConf, curl in phobos must go.

The plan is as follows.

1. undocument everything curl related in may 2016
2. deprecate everything curl related in may 2017
3. delete everything curl related in may 2018
3.1 move curl stuff to undead

PR: https://github.com/dlang/phobos/pull/4283
May 06 2016
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Fri, 06 May 2016 08:32:03 +0000
schrieb Robert burner Schadek <rburners gmail.com>:

 As discussed yesterday at DConf, curl in phobos must go.
 
 The plan is as follows.
 
 1. undocument everything curl related in may 2016
 2. deprecate everything curl related in may 2017
 3. delete everything curl related in may 2018
 3.1 move curl stuff to undead
 
 PR: https://github.com/dlang/phobos/pull/4283
Wouldn't it make sense to do 3.1 right now so people can switch earlier?
May 06 2016
parent reply Robert burner Schadek <rburners gmail.com> writes:
On Friday, 6 May 2016 at 08:43:09 UTC, Johannes Pfau wrote:
 Wouldn't it make sense to do 3.1 right now so people can switch 
 earlier?
Then every bugfix to curl needs to be put in two repos. And the idea is that people have two years to find a better solution. So hopefully when we put curl in undead in 2018 nobody is using it anymore.
May 06 2016
next sibling parent reply Dicebot <public dicebot.lv> writes:
On 05/06/2016 10:53 AM, Robert burner Schadek wrote:
 On Friday, 6 May 2016 at 08:43:09 UTC, Johannes Pfau wrote:
 Wouldn't it make sense to do 3.1 right now so people can switch earlier?
Then every bugfix to curl needs to be put in two repos. And the idea is that people have two years to find a better solution. So hopefully when we put curl in undead in 2018 nobody is using it anymore.
Deprecated modules don't get bugfixes. It is quite important to put it into undead the same moment it gets deprecated because there is no real replacement available so existing projects must have a clean migration path to keep working.
May 06 2016
next sibling parent Robert burner Schadek <rburners gmail.com> writes:
On Friday, 6 May 2016 at 09:00:24 UTC, Dicebot wrote:
 Deprecated modules don't get bugfixes. It
 is quite important to put it into undead the same moment it gets
 deprecated because there is no real replacement available so 
 existing
 projects must have a clean migration path to keep working.
sounds fair enough so the changed schedule is 1. undocument everything curl related in may 2016 2. deprecate everything curl related in may 2017 2.1 move curl stuff to undead 2.2 no more bugfixes for curl stuff 3. delete everything curl related in phobos in may 2018
May 06 2016
prev sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 6 May 2016 at 09:00:24 UTC, Dicebot wrote:
 Deprecated modules don't get bugfixes.
Isn't deprecated functionality tested in Phobos?
May 06 2016
parent Dicebot <public dicebot.lv> writes:
On 05/06/2016 12:19 PM, Kagamin wrote:
 On Friday, 6 May 2016 at 09:00:24 UTC, Dicebot wrote:
 Deprecated modules don't get bugfixes.
Isn't deprecated functionality tested in Phobos?
Yes, to ensure it doesn't get broken by changes to other symbols. But it doesn't get new bugfixes for actual deprecated symbols/modules normally.
May 06 2016
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/6/16 10:53 AM, Robert burner Schadek wrote:
 On Friday, 6 May 2016 at 08:43:09 UTC, Johannes Pfau wrote:
 Wouldn't it make sense to do 3.1 right now so people can switch earlier?
Then every bugfix to curl needs to be put in two repos. And the idea is that people have two years to find a better solution. So hopefully when we put curl in undead in 2018 nobody is using it anymore.
This is not a problem. Curl API isn't changing. I think it's a good idea to have it in undead early. -Steve
May 06 2016
prev sibling next sibling parent Andrea Fontana <nospam example.com> writes:
On Friday, 6 May 2016 at 08:32:03 UTC, Robert burner Schadek 
wrote:
 As discussed yesterday at DConf, curl in phobos must go.

 The plan is as follows.

 1. undocument everything curl related in may 2016
 2. deprecate everything curl related in may 2017
 3. delete everything curl related in may 2018
 3.1 move curl stuff to undead

 PR: https://github.com/dlang/phobos/pull/4283
I hope a replacement is planned, isn't it? Andrea
May 06 2016
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
On Friday, 6 May 2016 at 08:32:03 UTC, Robert burner Schadek 
wrote:
 As discussed yesterday at DConf, curl in phobos must go.

 The plan is as follows.

 1. undocument everything curl related in may 2016
 2. deprecate everything curl related in may 2017
 3. delete everything curl related in may 2018
 3.1 move curl stuff to undead

 PR: https://github.com/dlang/phobos/pull/4283
Give it to the doom guy: https://www.youtube.com/watch?v=3SAFSz8yxrE
May 06 2016
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/6/16 10:32 AM, Robert burner Schadek wrote:
 As discussed yesterday at DConf, curl in phobos must go.

 The plan is as follows.

 1. undocument everything curl related in may 2016
 2. deprecate everything curl related in may 2017
 3. delete everything curl related in may 2018
 3.1 move curl stuff to undead

 PR: https://github.com/dlang/phobos/pull/4283
0. Write curl replacement
May 06 2016
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/6/16 11:21 AM, Andrei Alexandrescu wrote:
 On 5/6/16 10:32 AM, Robert burner Schadek wrote:
 As discussed yesterday at DConf, curl in phobos must go.

 The plan is as follows.

 1. undocument everything curl related in may 2016
 2. deprecate everything curl related in may 2017
 3. delete everything curl related in may 2018
 3.1 move curl stuff to undead

 PR: https://github.com/dlang/phobos/pull/4283
0. Write curl replacement
So push dates to 2026-2028 then? ;) -Steve
May 06 2016
parent Dicebot <public dicebot.lv> writes:
On 05/06/2016 11:24 AM, Steven Schveighoffer wrote:
 So push dates to 2026-2028 then? ;)
 
 -Steve
D3 will fix EVERYTHING
May 06 2016
prev sibling next sibling parent reply yawniek <dlang srtnwz.com> writes:
On Friday, 6 May 2016 at 09:21:43 UTC, Andrei Alexandrescu wrote:
 On 5/6/16 10:32 AM, Robert burner Schadek wrote:
 As discussed yesterday at DConf, curl in phobos must go.

 The plan is as follows.

 1. undocument everything curl related in may 2016
 2. deprecate everything curl related in may 2017
 3. delete everything curl related in may 2018
 3.1 move curl stuff to undead

 PR: https://github.com/dlang/phobos/pull/4283
0. Write curl replacement
https://github.com/ikod/dlang-requests looks very promising, maybe it could be re-licenced?
May 06 2016
parent reply ikod <geller.garry gmail.com> writes:
On Friday, 6 May 2016 at 10:27:54 UTC, yawniek wrote:
 On Friday, 6 May 2016 at 09:21:43 UTC, Andrei Alexandrescu 
 wrote:
 On 5/6/16 10:32 AM, Robert burner Schadek wrote:
 As discussed yesterday at DConf, curl in phobos must go.

 The plan is as follows.

 1. undocument everything curl related in may 2016
 2. deprecate everything curl related in may 2017
 3. delete everything curl related in may 2018
 3.1 move curl stuff to undead

 PR: https://github.com/dlang/phobos/pull/4283
0. Write curl replacement
https://github.com/ikod/dlang-requests looks very promising, maybe it could be re-licenced?
Hello, Just some notes... I'm going to add some missed features like cookies, file downloads, maybe other high level features. My goal is something like python "requests" library. What do you mean under re-licensing?
May 07 2016
next sibling parent Suliman <evermind live.ru> writes:
 https://github.com/ikod/dlang-requests
+1 for dlang-requests. Thanks for it! I already use it's in my project, and it's very easy to use.
May 07 2016
prev sibling parent reply yawniek <dlang srtnwz.com> writes:
On Saturday, 7 May 2016 at 09:46:36 UTC, ikod wrote:
 What do you mean under re-licensing?
you added GPL to requests, this is incompatible with phobos and your code can not be included. could it be changed to boost licence?
May 07 2016
parent ikod <igor.khasilev gmail.com> writes:
On Saturday, 7 May 2016 at 21:03:36 UTC, yawniek wrote:
 On Saturday, 7 May 2016 at 09:46:36 UTC, ikod wrote:
 What do you mean under re-licensing?
you added GPL to requests, this is incompatible with phobos and your code can not be included. could it be changed to boost licence?
Hello, Yes, I think. Both licenses recognized as FOSS licenses, so there would be no problem. Thanks, Igor
May 08 2016
prev sibling parent reply qznc <qznc web.de> writes:
On Friday, 6 May 2016 at 09:21:43 UTC, Andrei Alexandrescu wrote:
 On 5/6/16 10:32 AM, Robert burner Schadek wrote:
 As discussed yesterday at DConf, curl in phobos must go.

 The plan is as follows.

 1. undocument everything curl related in may 2016
 2. deprecate everything curl related in may 2017
 3. delete everything curl related in may 2018
 3.1 move curl stuff to undead

 PR: https://github.com/dlang/phobos/pull/4283
0. Write curl replacement
Could we simply move it into a dub package? Or does that clash symbols or anything somehow?
May 06 2016
parent Lionello Lunesu <lionello lunesu.remove.com> writes:
On 6/5/2016 20:17, qznc wrote:
 On Friday, 6 May 2016 at 09:21:43 UTC, Andrei Alexandrescu wrote:
 On 5/6/16 10:32 AM, Robert burner Schadek wrote:
 As discussed yesterday at DConf, curl in phobos must go.

 The plan is as follows.

 1. undocument everything curl related in may 2016
 2. deprecate everything curl related in may 2017
 3. delete everything curl related in may 2018
 3.1 move curl stuff to undead

 PR: https://github.com/dlang/phobos/pull/4283
0. Write curl replacement
Could we simply move it into a dub package? Or does that clash symbols or anything somehow?
Just tried this, works fine! Try it yourself: $ sed -i '' 's/curl //' phobos/posix.mak $ make -C phobos -f posix.mak clean $ make -C phobos -f posix.mak $ dub init undead-curl $ echo 'targetType "sourceLibrary"' >> undead-curl/dub.sdl $ mkdir -p undead-curl/source/etc/c undead-curl/source/std/net/ $ mv phobos/etc/c/curl.d undead-curl/source/etc/c/ $ mv phobos/std/net/curl.d undead-curl/source/std/net/ $ dub add-local undead-curl Tested with an app I had made not long ago (guess what it does!) $ cd sciamspider $ echo 'dependency "undead-curl" version="~master"' >> dub.sdl $ dub Ran without any changes!
May 08 2016
prev sibling next sibling parent Dsby <dushibaiyu yahoo.com> writes:
On Friday, 6 May 2016 at 08:32:03 UTC, Robert burner Schadek 
wrote:
 As discussed yesterday at DConf, curl in phobos must go.

 The plan is as follows.

 1. undocument everything curl related in may 2016
 2. deprecate everything curl related in may 2017
 3. delete everything curl related in may 2018
 3.1 move curl stuff to undead

 PR: https://github.com/dlang/phobos/pull/4283
Frist , we should have some to replacement curl. http1.x and http2 resquest.
May 06 2016
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 06 May 2016 08:32:03 +0000
Robert burner Schadek via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 As discussed yesterday at DConf, curl in phobos must go.

 The plan is as follows.

 1. undocument everything curl related in may 2016
 2. deprecate everything curl related in may 2017
 3. delete everything curl related in may 2018
 3.1 move curl stuff to undead

 PR: https://github.com/dlang/phobos/pull/4283
Aside from the issue of a replacement, the normal deprecation process is to deprecate the symbol (or module) but leave it in the documentation for a year; then the documentation is removed, but the code remains for another year; and then after that year, the code is removed. So, steps 1 and 2 should be swapped. However, we _can_ put a message in the documentation about how we intend to remove it (along with a short reason for it) so that folks are aware that if they use it, they're going to need to change their code later. We've done that with other modules previously (e.g. std.xml). The main problem, of course, is then actually getting a replacement, which we have freqently done a poor job of doing. - Jonathan M Davis
May 06 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 6 May 2016 at 13:12:31 UTC, Jonathan M Davis wrote:
 The main problem, of course, is then actually getting a 
 replacement, which we have freqently done a poor job of doing.
I have an HTTP client lib, I'm pretty sure Vladimir does too, and I think vibe wrote one for their framework. I'm sure we're not the only ones. I also have an XML lib, and again, I'm pretty sure Vladimir does too... I'm not really interested in going in Phobos, my dev pace is different than their's (when I use it on real world stuff, I do fast development, and when not, I'm busy with other stuff and it sits...) and my style is different too. BUT, if someone wanted to partner and do the boring Phobos crap I'm not doing myself, I'd help with everything else. But nevertheless, the D community has the code already or these replacements - it is just a question of Phobos joining forces with the existing efforts.
May 06 2016
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 06 May 2016 13:25:55 +0000
"Adam D. Ruppe via Digitalmars-d" <digitalmars-d puremagic.com> wrote:
 But nevertheless, the D community has the code already or these
 replacements - it is just a question of Phobos joining forces
 with the existing efforts.
That is a bit of a classic problem that we seem to have. Folks do cool stuff but don't want to make the extra effort to get it into Phobos. So, it exists - and is up on code.dlang.org in many cases - but Phobos never gets the improvement. Replacing curl is definitely something that should be able to do fairly quickly so long as someone is willing and able to put in the time and effort required to get a solid submission ready and push it through the review queue. - Jonathan M Davis
May 06 2016
parent Kagamin <spam here.lot> writes:
On Friday, 6 May 2016 at 14:31:56 UTC, Jonathan M Davis wrote:
 That is a bit of a classic problem that we seem to have. Folks 
 do cool stuff but don't want to make the extra effort to get it 
 into Phobos.
Maybe somehow reduce or divide the required effort?
May 06 2016
prev sibling parent reply Jonas Drewsen <nospam4321 hotmail.com> writes:
On Friday, 6 May 2016 at 13:25:55 UTC, Adam D. Ruppe wrote:
 On Friday, 6 May 2016 at 13:12:31 UTC, Jonathan M Davis wrote:
 [...]
I have an HTTP client lib, I'm pretty sure Vladimir does too, and I think vibe wrote one for their framework. I'm sure we're not the only ones. I also have an XML lib, and again, I'm pretty sure Vladimir does too... [...]
But std.net.curl supports not just HTTP but also FTP etc. so i guess that won't suffice.
May 07 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 7 May 2016 at 20:50:53 UTC, Jonas Drewsen wrote:
 But std.net.curl supports not just HTTP but also FTP etc. so i 
 guess that won't suffice.
We can always implement ftp too, it isn't that complicated of a protocol. Though, I suspect its users are a tiny minority and they might not mind depending on a separate curl package.
May 07 2016
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sunday, May 08, 2016 02:44:48 Adam D. Ruppe via Digitalmars-d wrote:
 On Saturday, 7 May 2016 at 20:50:53 UTC, Jonas Drewsen wrote:
 But std.net.curl supports not just HTTP but also FTP etc. so i
 guess that won't suffice.
We can always implement ftp too, it isn't that complicated of a protocol. Though, I suspect its users are a tiny minority and they might not mind depending on a separate curl package.
An alternative would be to move std.net.curl into a dub package. And even if we want to have a Phobos replacement for std.net.curl before ripping it out rather than just redirecting folks to a dub package, we could still take the approach of replacing the primary stuff that std.net.curl does without necessarily replacing all of it, since it would still be easy to use what we have now by grabbing it from dub. And it _is_ the sort of thing that makes perfect sense as a dub package. - Jonathan M Davis
May 08 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/8/16 11:05 AM, Jonathan M Davis via Digitalmars-d wrote:
 On Sunday, May 08, 2016 02:44:48 Adam D. Ruppe via Digitalmars-d wrote:
 On Saturday, 7 May 2016 at 20:50:53 UTC, Jonas Drewsen wrote:
 But std.net.curl supports not just HTTP but also FTP etc. so i
 guess that won't suffice.
We can always implement ftp too, it isn't that complicated of a protocol. Though, I suspect its users are a tiny minority and they might not mind depending on a separate curl package.
An alternative would be to move std.net.curl into a dub package.
That would still be a breaking change, is that correct? I'm unclear on what the reasons are for removing libcurl so I'd love to see them stated clearly. Walter's argumentation was vague - code that we don't control etc. There have been past reports of issues with libcurl on windows, have those not been permanently solved? I even see a plus: dealing with libcurl is a good exercise in eating our dogfood regarding "interfacing with C libraries is trivial" stance. Having to deal with it is a reflection of what other projects have to do on an ongoing basis. Andrei
May 08 2016
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/8/16 10:33 AM, Andrei Alexandrescu wrote:
 On 5/8/16 11:05 AM, Jonathan M Davis via Digitalmars-d wrote:
 On Sunday, May 08, 2016 02:44:48 Adam D. Ruppe via Digitalmars-d wrote:
 On Saturday, 7 May 2016 at 20:50:53 UTC, Jonas Drewsen wrote:
 But std.net.curl supports not just HTTP but also FTP etc. so i
 guess that won't suffice.
We can always implement ftp too, it isn't that complicated of a protocol. Though, I suspect its users are a tiny minority and they might not mind depending on a separate curl package.
An alternative would be to move std.net.curl into a dub package.
That would still be a breaking change, is that correct? I'm unclear on what the reasons are for removing libcurl so I'd love to see them stated clearly. Walter's argumentation was vague - code that we don't control etc. There have been past reports of issues with libcurl on windows, have those not been permanently solved?
My understanding is that libcurl isn't default installed on some platforms (e.g. windows). So we have a dependency on an external library that may not be present. If in "first five minutes" user wants to execute downloads from http server and is told "oh, to use Phobos, you must download another library, sorry", I don't think that helps. Ironically, zlib is statically compiled by the build, always included, it's not changing anytime soon (Latest release is April 2013), and so requires zero maintenance. Since it's statically in phobos, it is zero pain to the end user. Yet that is the one you want to remove over libcurl? I agree the D wrapper needs re-implementing, but the C library part of it is rock-solid. -Steve
May 08 2016
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 8 May 2016 at 09:43:14 UTC, Steven Schveighoffer wrote:
 My understanding is that libcurl isn't default installed on 
 some platforms (e.g. windows). So we have a dependency on an 
 external library that may not be present. If in "first five 
 minutes" user wants to execute downloads from http server and 
 is told "oh, to use Phobos, you must download another library, 
 sorry", I don't think that helps.
I understand that this is no longer a problem. We link dynamically to the DLL, which is distributed with DMD, and it's lazy-loaded (so we don't do anything at all until the first std.net.curl function is called).
May 08 2016
parent reply krzaq <dlangmailinglist krzaq.cc> writes:
On Sunday, 8 May 2016 at 13:31:46 UTC, Vladimir Panteleev wrote:
 On Sunday, 8 May 2016 at 09:43:14 UTC, Steven Schveighoffer 
 wrote:
 My understanding is that libcurl isn't default installed on 
 some platforms (e.g. windows). So we have a dependency on an 
 external library that may not be present. If in "first five 
 minutes" user wants to execute downloads from http server and 
 is told "oh, to use Phobos, you must download another library, 
 sorry", I don't think that helps.
I understand that this is no longer a problem. We link dynamically to the DLL, which is distributed with DMD, and it's lazy-loaded (so we don't do anything at all until the first std.net.curl function is called).
That could lead to some nasty surprises when distributing a binary. I'd rather hear my customer say "I can't start your program, because some .dll is missing" than "it randomly crashes / doesn't work".
May 10 2016
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Tuesday, 10 May 2016 at 14:19:15 UTC, krzaq wrote:
 On Sunday, 8 May 2016 at 13:31:46 UTC, Vladimir Panteleev wrote:
 On Sunday, 8 May 2016 at 09:43:14 UTC, Steven Schveighoffer 
 wrote:
 [...]
I understand that this is no longer a problem. We link dynamically to the DLL, which is distributed with DMD, and it's lazy-loaded (so we don't do anything at all until the first std.net.curl function is called).
That could lead to some nasty surprises when distributing a binary. I'd rather hear my customer say "I can't start your program, because some .dll is missing" than "it randomly crashes / doesn't work".
You imply that the error message that Druntime generates when it cannot find the DLL is significantly worse than the error message that the OS generates when it cannot find the DLL.
May 10 2016
parent reply krzaq <dlangmailinglist krzaq.cc> writes:
On Tuesday, 10 May 2016 at 14:26:27 UTC, Vladimir Panteleev wrote:
 On Tuesday, 10 May 2016 at 14:19:15 UTC, krzaq wrote:
 On Sunday, 8 May 2016 at 13:31:46 UTC, Vladimir Panteleev 
 wrote:
 On Sunday, 8 May 2016 at 09:43:14 UTC, Steven Schveighoffer 
 wrote:
 [...]
I understand that this is no longer a problem. We link dynamically to the DLL, which is distributed with DMD, and it's lazy-loaded (so we don't do anything at all until the first std.net.curl function is called).
That could lead to some nasty surprises when distributing a binary. I'd rather hear my customer say "I can't start your program, because some .dll is missing" than "it randomly crashes / doesn't work".
You imply that the error message that Druntime generates when it cannot find the DLL is significantly worse than the error message that the OS generates when it cannot find the DLL.
Even if it's better, it's significantly *later*. Once my code runs in a production environment I'd really prefer it to not to stop over things that could've easily been prevented.
May 10 2016
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Tuesday, 10 May 2016 at 14:35:17 UTC, krzaq wrote:
 On Tuesday, 10 May 2016 at 14:26:27 UTC, Vladimir Panteleev 
 wrote:
 On Tuesday, 10 May 2016 at 14:19:15 UTC, krzaq wrote:
 On Sunday, 8 May 2016 at 13:31:46 UTC, Vladimir Panteleev 
 wrote:
 On Sunday, 8 May 2016 at 09:43:14 UTC, Steven Schveighoffer 
 wrote:
 [...]
I understand that this is no longer a problem. We link dynamically to the DLL, which is distributed with DMD, and it's lazy-loaded (so we don't do anything at all until the first std.net.curl function is called).
That could lead to some nasty surprises when distributing a binary. I'd rather hear my customer say "I can't start your program, because some .dll is missing" than "it randomly crashes / doesn't work".
You imply that the error message that Druntime generates when it cannot find the DLL is significantly worse than the error message that the OS generates when it cannot find the DLL.
Even if it's better, it's significantly *later*. Once my code runs in a production environment I'd really prefer it to not to stop over things that could've easily been prevented.
You can actually still statically link libcurl to the executable if you so desire. Regardless, I'm not sure that we should worry much about the particular case where you 1) link to libcurl dynamically 2) distribute an incomplete application with some DLLs missing and 3) use libcurl late during your application's runtime.
May 10 2016
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tuesday, May 10, 2016 14:51:02 Vladimir Panteleev via Digitalmars-d wrote:
 On Tuesday, 10 May 2016 at 14:35:17 UTC, krzaq wrote:
 On Tuesday, 10 May 2016 at 14:26:27 UTC, Vladimir Panteleev
 wrote:
 You imply that the error message that Druntime generates when
 it cannot find the DLL is significantly worse than the error
 message that the OS generates when it cannot find the DLL.
Even if it's better, it's significantly *later*. Once my code runs in a production environment I'd really prefer it to not to stop over things that could've easily been prevented.
You can actually still statically link libcurl to the executable if you so desire. Regardless, I'm not sure that we should worry much about the particular case where you 1) link to libcurl dynamically 2) distribute an incomplete application with some DLLs missing and 3) use libcurl late during your application's runtime.
Testing is supposed to fix that sort of thing. And since you _can_ statically link against libcurl if you want to, then you can still get the compile time error, and I really don't see such issues as a viable argument either. I do wish that std.net.curl were a dub package rather than in Phobos, but having issues where you forgot to include libcurl's dll with your binary is a separate issue. - Jonathan M Davis
May 10 2016
prev sibling next sibling parent reply Suliman <evermind live.ru> writes:
Andrei, is there any plans to drop etc.c.odbc ?
May 08 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/8/16 5:37 PM, Suliman wrote:
 Andrei, is there any plans to drop etc.c.odbc ?
No. -- Andrei
May 08 2016
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sunday, May 08, 2016 11:33:07 Andrei Alexandrescu via Digitalmars-d wrote:
 On 5/8/16 11:05 AM, Jonathan M Davis via Digitalmars-d wrote:
 On Sunday, May 08, 2016 02:44:48 Adam D. Ruppe via Digitalmars-d wrote:
 On Saturday, 7 May 2016 at 20:50:53 UTC, Jonas Drewsen wrote:
 But std.net.curl supports not just HTTP but also FTP etc. so i
 guess that won't suffice.
We can always implement ftp too, it isn't that complicated of a protocol. Though, I suspect its users are a tiny minority and they might not mind depending on a separate curl package.
An alternative would be to move std.net.curl into a dub package.
That would still be a breaking change, is that correct?
Any replacement would be a breaking change, unless the intention is to keep to std.net.curl's API while ripping out the actual curl usage, and that seems unnecessarily restrictive to me and likely to end up with something inferior to what we would otherwise get. IIRC, we've already had issues with std.net.curl not quite doing what we want (though at least some of those could likely be fixed if we have full control over what the underlying code is doing). But given that std.net.curl handles stuff like SSL/TLS, we _can't_ actually replace all of its functionality - at least not without adding a dependency on a different C library, since there's no way that it's sane to do the crypto stuff ourselves without a crypto expert, and even then, we should think twice about it. I could see implementing the SSL/TLS protocols themselves but not the crypto they use. If we replace std.net.curl, we likely should just provide the basic HTTP functionality, and leave the rest to a dub package that we move std.net.curl to. But even if we did manage to replace all of std.net.curl's functionality in Phobos, I definitely think that we should put in dub. Whatever problems we've had with it, they're definitely not bad enough for us to want to eradicate it as D code, just remove it from Phobos. And if it were a dub package, updating your code to use it should be pretty trivial. Once std.net.curl was deprecated in Phobos, and it was put in dub as a separate package, anyone who wanted to update would just change their import statements to use the module name from the dub package and add it as a dependency to their dub.json/dub.sdl file. So, as far as breaking changes go, moving std.net.curl from Phobos to code.dlang.org would be very easy to deal with.
 I'm unclear on what the reasons are for removing libcurl so I'd love to
 see them stated clearly. Walter's argumentation was vague - code that we
 don't control etc. There have been past reports of issues with libcurl
 on windows, have those not been permanently solved?

 I even see a plus: dealing with libcurl is a good exercise in eating our
 dogfood regarding "interfacing with C libraries is trivial" stance.
 Having to deal with it is a reflection of what other projects have to do
 on an ongoing basis.
Walter's main complaint seemed to be that he didn't like the idea of depending on C libraries other than the C runtime in our standard library, since it meant that there was code in our standard library that we did not have control of, and it arguably looks bad to have to use C libraries in our own standard library. But the big problem that I'm aware of has had to do with the fact that we then have an external dependency that not everyone has on their system. Even on Linux, on distros that separate out "dev" packages so that you have to install one package to use a library and another to build code using it, libcurl is not necessarily going to be there to be built against (and it's definitely not on Windows normally). And that's definitely caused problems - though including libcurl with the dmd installer (which we didn't do initially) has reduced those problems. Personally, I've run into issues with the tools repo due to its dependence on std.net.curl, and while that may be related to issues on my system rather than anything that's been done with Phobos itself, that doesn't exactly give me warm, fuzzy feelings for std.net.curl. In addition, Phobos is not tied to curl's release cycle, and if curl gets a version bump on someone's system, and Phobos hasn't been updated to match, they're going to have a problem. And if we updated to match the version bump, and their distro hadn't, then we'd also have a problem. AFAIK, curl's API has been fairly stable such that this hasn't been a problem, but it's definitely a concern with C libraries in general, and it was pointed out at dconf that it _is_ a problem with the sqlite bindings. So, even if we decide to keep std.net.curl, I think that versioning issues alone should make us very leery of including C libraries in Phobos - be they via bindings or wrappers. I don't think that we want to be in a situation where someone has to use a specific version of dmd and Phobos, because it's the one that matches a C library on their system that Phobos depends on. And while that might be manageable with one C library dependency, it likely wouldn't be with multiple. Having such dependencies in dub packages should make it easier to manage them. Another thing to consider is portability. Just because a library is written in C doesn't mean that it's going to work on all of the targets that we want to hit with dmd, ldc, and gdc. We have control over that sort of thing if the code is in D. We don't if it's in C. From the looks of it, curl is available for the vast majority of platforms, so this likely won't be a problem with curl, but it is a reason to think twice before considering adding another dependency on a C library to Phobos. If std.net.curl were not already in Phobos, I think that it's quite clear that it would be a great fit for a dub package, and I would definitely vote against its inclusion in Phobos. And at this point, I will likely do the same for any C library. I think that those all belong on code.dlang.org and not in Phobos. - Jonathan M Davis
May 09 2016
next sibling parent reply sigod <sigod.mail gmail.com> writes:
On Monday, 9 May 2016 at 08:55:36 UTC, Jonathan M Davis wrote:
 But given that std.net.curl handles stuff like SSL/TLS, we 
 _can't_ actually replace all of its functionality - at least 
 not without adding a dependency on a different C library, since 
 there's no way that it's sane to do the crypto stuff ourselves 
 without a crypto expert, and even then, we should think twice 
 about it. I could see implementing the SSL/TLS protocols 
 themselves but not the crypto they use. If we replace 
 std.net.curl, we likely should just provide the basic HTTP 
 functionality, and leave the rest to a dub package that we move 
 std.net.curl to.
Any chances that we can produce good crypto code over time? And verify it with experts, of course.
 In addition, Phobos is not tied to curl's release cycle, and if 
 curl gets a version bump on someone's system, and Phobos hasn't 
 been updated to match, they're going to have a problem. And if 
 we updated to match the version bump, and their distro hadn't, 
 then we'd also have a problem.
Oh, that explains why I constantly ran into [this issue][0]. While it was fixed in curl itself. [0]: https://github.com/curl/curl/issues/447
May 09 2016
next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, May 09, 2016 09:35:18 sigod via Digitalmars-d wrote:
 On Monday, 9 May 2016 at 08:55:36 UTC, Jonathan M Davis wrote:
 But given that std.net.curl handles stuff like SSL/TLS, we
 _can't_ actually replace all of its functionality - at least
 not without adding a dependency on a different C library, since
 there's no way that it's sane to do the crypto stuff ourselves
 without a crypto expert, and even then, we should think twice
 about it. I could see implementing the SSL/TLS protocols
 themselves but not the crypto they use. If we replace
 std.net.curl, we likely should just provide the basic HTTP
 functionality, and leave the rest to a dub package that we move
 std.net.curl to.
Any chances that we can produce good crypto code over time? And verify it with experts, of course.
I'm sure that it's possible, but it's also very dangerous territory to deal with. Even if you get the crypto itself right, there are all kinds of other nasty problems you have to worry about that most people won't - like ensuring that certain operations take the same amount of time regardless of whether they succeed or not so that folks snooping can't figure out what is and isn't succeeding. There's also the issue of keeping up-to-date with which protocols should be used and which shouldn't (e.g. if I understand correctly, pretty much nothing should be using SSL now; it should all be TLS). So, while there is no technical barrier to us implementing all of this in D (the crypto itself included), it's a very tall order to get it right. Having the code vetted by experts would _definitely_ help, but it's going to go a lot better if we have a security expert writing and maintaining the code, and I'm not sure that we have anyone like that among our active contributors right now (though someone like that is definitely welcome to start contributing code). I actually considered implementing SSL in D at one point (with the idea that I'd use a C or C++ library for the crypto itself), but the more that I learn about this stuff, the more leery I am of implementing anything that's in the security domain. And the only way that I would ever consider doing the crypto itself would be by porting C code that did it, and even that seems pretty hairy - especially since I wouldn't have the knowledge necessary to maintain it. So, we may very well end up with full-on crypto stuff written in D at some point - maybe even in the standard library - but it's something that we need to be very careful with. - Jonathan M Davis
May 09 2016
prev sibling parent reply ZombineDev <petar.p.kirov gmail.com> writes:
On Monday, 9 May 2016 at 09:35:18 UTC, sigod wrote:
 On Monday, 9 May 2016 at 08:55:36 UTC, Jonathan M Davis wrote:
 But given that std.net.curl handles stuff like SSL/TLS, we 
 _can't_ actually replace all of its functionality - at least 
 not without adding a dependency on a different C library, 
 since there's no way that it's sane to do the crypto stuff 
 ourselves without a crypto expert, and even then, we should 
 think twice about it. I could see implementing the SSL/TLS 
 protocols themselves but not the crypto they use. If we 
 replace std.net.curl, we likely should just provide the basic 
 HTTP functionality, and leave the rest to a dub package that 
 we move std.net.curl to.
Any chances that we can produce good crypto code over time? And verify it with experts, of course.
https://github.com/etcimon/botan AFAIK, it is already used in production by its author, in combination with libasync + vibe.d + http2 for a full stack D solution.
 ...
May 09 2016
parent reply Seb <seb wilzba.ch> writes:
On Monday, 9 May 2016 at 10:44:13 UTC, ZombineDev wrote:
 On Monday, 9 May 2016 at 09:35:18 UTC, sigod wrote:
 On Monday, 9 May 2016 at 08:55:36 UTC, Jonathan M Davis wrote:
 But given that std.net.curl handles stuff like SSL/TLS, we 
 _can't_ actually replace all of its functionality - at least 
 not without adding a dependency on a different C library, 
 since there's no way that it's sane to do the crypto stuff 
 ourselves without a crypto expert, and even then, we should 
 think twice about it. I could see implementing the SSL/TLS 
 protocols themselves but not the crypto they use. If we 
 replace std.net.curl, we likely should just provide the basic 
 HTTP functionality, and leave the rest to a dub package that 
 we move std.net.curl to.
Any chances that we can produce good crypto code over time? And verify it with experts, of course.
https://github.com/etcimon/botan AFAIK, it is already used in production by its author, in combination with libasync + vibe.d + http2 for a full stack D solution.
So what's the consensus on this issue? Can't we simply move std.net.curl and etc.c.curl to undead and just _not_ include it in Phobos? Anyone reasonable will use requests [1], vibe.d's async requestHTTP [2] or their home-grown library anyways. As mentioned in another thread [3], Phobos is bloated with "old" modules that wouldn't have made it through today's review process. With DUB's "new" single file feature and DUB being bundled in the DMD release process, any DUB library is just a header comment away. Moreover we can configure the DUB package to automatically compile the curl sources, so that it won't create any troubles as e.g. the people on Windows or the gdc maintainers experience. [1] https://github.com/ikod/dlang-requests [2] vibed.org/api/vibe.http.client/requestHTTP [3] http://forum.dlang.org/post/odbddahgxadkffbwcuje forum.dlang.org
Feb 18
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Seb wrote:
 So what's the consensus on this issue?
leave curl where it is now. i am teh user. i have alot of code depending on std.net.curl. i hope that "we are not breaking user's code" motto is not just a PR slogan.
Feb 18
parent Chris Wright <dhasenan gmail.com> writes:
On Sat, 18 Feb 2017 21:41:51 +0000, ketmar wrote:

 Seb wrote:
 So what's the consensus on this issue?
leave curl where it is now. i am teh user. i have alot of code depending on std.net.curl. i hope that "we are not breaking user's code" motto is not just a PR slogan.
I've got a fair bit too.
Feb 18
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 2/18/17 10:20 PM, Seb wrote:
 On Monday, 9 May 2016 at 10:44:13 UTC, ZombineDev wrote:
 On Monday, 9 May 2016 at 09:35:18 UTC, sigod wrote:
 On Monday, 9 May 2016 at 08:55:36 UTC, Jonathan M Davis wrote:
 But given that std.net.curl handles stuff like SSL/TLS, we _can't_
 actually replace all of its functionality - at least not without
 adding a dependency on a different C library, since there's no way
 that it's sane to do the crypto stuff ourselves without a crypto
 expert, and even then, we should think twice about it. I could see
 implementing the SSL/TLS protocols themselves but not the crypto
 they use. If we replace std.net.curl, we likely should just provide
 the basic HTTP functionality, and leave the rest to a dub package
 that we move std.net.curl to.
Any chances that we can produce good crypto code over time? And verify it with experts, of course.
https://github.com/etcimon/botan AFAIK, it is already used in production by its author, in combination with libasync + vibe.d + http2 for a full stack D solution.
So what's the consensus on this issue? Can't we simply move std.net.curl and etc.c.curl to undead and just _not_ include it in Phobos? Anyone reasonable will use requests [1], vibe.d's async requestHTTP [2] or their home-grown library anyways. As mentioned in another thread [3], Phobos is bloated with "old" modules that wouldn't have made it through today's review process.
For some time I was a proponent of yanking stuff from Phobos into oblivion. Now I'm not. Stop breaking code. Yes, we should think harder before introducing libraries into Phobos but continuing on with removal of stuff just introduces the continuous churn for no adequate benefit. What would anyone get from std.net.curl removal? Are you going to find all of D programs and patch them to use something else? Yes, Phobos is full of historical accidents and cruft. I'm constantly tempted to propose Phobos v2 properly _designed_ (not *grown*) and without the junk. I really think it might be a good idea but only when we actually know what a proper design looks like. --- Dmitry Olshansky
Feb 18
next sibling parent Seb <seb wilzba.ch> writes:
On Saturday, 18 February 2017 at 22:48:53 UTC, Dmitry Olshansky 
wrote:
 Yes, Phobos is full of historical accidents and cruft. I'm 
 constantly tempted to propose Phobos v2 properly _designed_ 
 (not *grown*) and without the junk. I really think it might be 
 a good idea but only when we actually know what a proper design 
 looks like.
You are not the only one! Did you follow Ilya's proposal about a betterC modular standard library? http://forum.dlang.org/post/phexetutyelrssyrucvw forum.dlang.org Unfortunately it died because of the fear of "balkanizing the community" with such a development... (though I am not sure how it could be more "balkanized" as atm everyone seems to grow their own home-made libraries)
Feb 18
prev sibling parent Matthias Klumpp <mak debian.org> writes:
On Saturday, 18 February 2017 at 22:48:53 UTC, Dmitry Olshansky 
wrote:
 [...]
 For some time I was a proponent of yanking stuff from Phobos 
 into oblivion. Now I'm not. Stop breaking code. Yes, we should 
 think harder before introducing libraries into Phobos but 
 continuing on with removal of stuff just introduces the 
 continuous churn for no adequate benefit.

 What would anyone get from std.net.curl removal? Are you going 
 to find all of D programs and patch them to use something else?

 Yes, Phobos is full of historical accidents and cruft. I'm 
 constantly tempted to propose Phobos v2 properly _designed_ 
 (not *grown*) and without the junk. I really think it might be 
 a good idea but only when we actually know what a proper design 
 looks like.
Due to writing the AppStream metadata generator in D, which is an infrastructure piece of many Linux distributions, I have a fair bit of knowledge now about the problems people (especially newcomers who just want to scratch an itch and submit a quick patch) encounter when working with D code. The inconsistent standard library is - after compiler bugs - the biggest issue. Some people described Phobos as "PHP-esque" in terms of design, and I have to agree with them. Working with it is often unpleasant, and you can clearly see which parts of it were designed recently and which are "historical accidents". Constantly shuffling stuff around in Phobos and adding/removing things will not solve the problem, it will just give newcomers a feeling of insecurity and make the language feel less mature. Stunningly, a lot of projects write their own primitives instead of using Phobos (Vibe, lots of dub modules just providing containers, just now another general purpose utility library was announced on the forums, ...) which is a clear sign that Phobos isn't seen to be sufficient. I think investigating to build a "Phobos2" standard library would be a very good idea - make it opt-in for a while, and then set a flag-date and switch, so people will only need to adjust their code once to jump on the new version, and don't constantly need to play catch with Phobos API breaks and riddle their code with version() and static if instructions to be able to compile with multiple Phobos and LDC/GDC/DMD versions. Cheers, Matthias
Feb 18
prev sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 9 May 2016 at 08:55:36 UTC, Jonathan M Davis wrote:
 Walter's main complaint seemed to be that he didn't like the 
 idea of depending on C libraries other than the C runtime in 
 our standard library, since it meant that there was code in our 
 standard library that we did not have control of, and it 
 arguably looks bad to have to use C libraries in our own 
 standard library. But the big problem that I'm aware of has had 
 to do with the fact that we then have an external dependency 
 that not everyone has on their system. Even on Linux, on 
 distros that separate out "dev" packages so that you have to 
 install one package to use a library and another to build code 
 using it, libcurl is not necessarily going to be there to be 
 built against (and it's definitely not on Windows normally). 
 And that's definitely caused problems - though including 
 libcurl with the dmd installer (which we didn't do initially) 
 has reduced those problems.
Martin has also made curl lazy-loaded, so you should not have any problems unless you both try to use curl and don't have the curl DLL in your PATH.
May 09 2016
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Sun, 8 May 2016 11:33:07 +0300
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:

 On 5/8/16 11:05 AM, Jonathan M Davis via Digitalmars-d wrote:
 On Sunday, May 08, 2016 02:44:48 Adam D. Ruppe via Digitalmars-d
 wrote:  
 On Saturday, 7 May 2016 at 20:50:53 UTC, Jonas Drewsen wrote:  
 But std.net.curl supports not just HTTP but also FTP etc. so i
 guess that won't suffice.  
We can always implement ftp too, it isn't that complicated of a protocol. Though, I suspect its users are a tiny minority and they might not mind depending on a separate curl package.
An alternative would be to move std.net.curl into a dub package.
That would still be a breaking change, is that correct? I'm unclear on what the reasons are for removing libcurl so I'd love to see them stated clearly. Walter's argumentation was vague - code that we don't control etc. There have been past reports of issues with libcurl on windows, have those not been permanently solved? I even see a plus: dealing with libcurl is a good exercise in eating our dogfood regarding "interfacing with C libraries is trivial" stance. Having to deal with it is a reflection of what other projects have to do on an ongoing basis. Andrei
The curl problems are more or less solved now, but it has caused quite some trouble: As long as we were statically linking curl: * We can't use curl when producing cross compilers for GDC as the minimal builds used by crosstool do not include curl. They do not even include zlib, we're just lucky that zlib is in GCC and we compile it statically into druntime. OTOH I'm not sure if we can get conflicts between our statically compiled zlib and libraries which link against zlib. * For static libraries, we don't need curl at link time, but for dynamic libraries we do need it. * There was the library versioning issue which made DMD builds unusable on some distributions. * http://bugzilla.gdcproject.org/show_bug.cgi?id=202 Even programs not using libcurl will sometimes require linking curl (This is because common templates such as std.conv.to might be instatiated in curl, so curl.o is pulled in, which depends on libcurl) * Library order when linking is important nowadays, so you need a way to specify -lcurl in the correct location relative to -lphobos Still open issues: * Even when dynamically loading curl, it introduces a new dependency: libdl for dynamic loading. This is not an issue for shared libraries, but the list of libraries which need to be hard coded when linking a static libphobos is already quite long: -lc -lrt -lm -ldl -lz -lstdc++ -luuid -lws2_32 In fact GDC doesn't link some of these yet and Iain doesn't want to add more special cases to our linking code (https://github.com/D-Programming-GDC/GDC/pull/182 https://github.com/D-Programming-GDC/GDC/pull/181). Additionally the complete API, integration with D features and performance is not really up to phobos standards. This is because of libcurl API limitations though, so there's nothing we can do about it. As long as we don't have a D replacement though, it's still the best HTTP client available...
May 13 2016
prev sibling next sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
I was at dconf, but missed the discussion where this was spoken 
of. I'm curious to know what is wrong with the curl wrapper. I've 
only recently been following D again after a gap of several years 
and remember curl being received quite favorablyt at the time, 
several people used it as an example of good api design.

Its such a useful and simple piece of functionality to have out 
of the box, greatly increasing the amount of interesting things 
you can do with D without installing additional packages. Phobos 
already has lackluster support for common web technologies, it 
would be a bummer if curl is deprecated before a replacement was 
in place.
May 07 2016
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/6/16 11:32 AM, Robert burner Schadek wrote:
 As discussed yesterday at DConf, curl in phobos must go.

 The plan is as follows.

 1. undocument everything curl related in may 2016
 2. deprecate everything curl related in may 2017
 3. delete everything curl related in may 2018
 3.1 move curl stuff to undead

 PR: https://github.com/dlang/phobos/pull/4283
Another library discussed as even more ripe for replacement is zlib: * We compile the C source code, which is extra aggravation to the build scripts * The D wrappers are ancient and clunky - we should have beautiful, efficient range streaming * I think the license allows us to translate the source code to D, so we have a viable path of replacement * Just got word (thx Rikki) the D wrappers use GC in a laissez-faire manner, so no way to use the library tightly So if anyone wants to look into this, it would be a good project. Andrei
May 07 2016
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/7/16 3:33 PM, Andrei Alexandrescu wrote:
 On 5/6/16 11:32 AM, Robert burner Schadek wrote:
 As discussed yesterday at DConf, curl in phobos must go.

 The plan is as follows.

 1. undocument everything curl related in may 2016
 2. deprecate everything curl related in may 2017
 3. delete everything curl related in may 2018
 3.1 move curl stuff to undead

 PR: https://github.com/dlang/phobos/pull/4283
Another library discussed as even more ripe for replacement is zlib: * We compile the C source code, which is extra aggravation to the build scripts * The D wrappers are ancient and clunky - we should have beautiful, efficient range streaming * I think the license allows us to translate the source code to D, so we have a viable path of replacement * Just got word (thx Rikki) the D wrappers use GC in a laissez-faire manner, so no way to use the library tightly So if anyone wants to look into this, it would be a good project.
I agree, I could not use the d wrappers for zlib when I made iopipe. I think Stefan Koch has created some zlib programs that are fully CTFE and D. -Steve
May 07 2016
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/7/2016 6:33 AM, Andrei Alexandrescu wrote:
 Another library discussed as even more ripe for replacement is zlib:
Started a new thread for this.
May 07 2016
prev sibling parent reply Gavin <nospam nospam.com> writes:
On Friday, 6 May 2016 at 08:32:03 UTC, Robert burner Schadek 
wrote:
 As discussed yesterday at DConf, curl in phobos must go.

 The plan is as follows.

 1. undocument everything curl related in may 2016
 2. deprecate everything curl related in may 2017
 3. delete everything curl related in may 2018
 3.1 move curl stuff to undead

 PR: https://github.com/dlang/phobos/pull/4283
Two of the most important modules in a standard library are containers & networking. In Phobos they are terrible. How about focusing on that than this nonsense? The Curl wrapper is about the only useful bit of networking code in the entire standard library. How on earth are you gonna compete with Go & Rust with useless container & networking modules?
Feb 18
parent Cym13 <cpicard openmailbox.org> writes:
On Sunday, 19 February 2017 at 04:00:33 UTC, Gavin wrote:
 On Friday, 6 May 2016 at 08:32:03 UTC, Robert burner Schadek 
 wrote:
 As discussed yesterday at DConf, curl in phobos must go.

 The plan is as follows.

 1. undocument everything curl related in may 2016
 2. deprecate everything curl related in may 2017
 3. delete everything curl related in may 2018
 3.1 move curl stuff to undead

 PR: https://github.com/dlang/phobos/pull/4283
Two of the most important modules in a standard library are containers & networking. In Phobos they are terrible. How about focusing on that than this nonsense? The Curl wrapper is about the only useful bit of networking code in the entire standard library. How on earth are you gonna compete with Go & Rust with useless container & networking modules?
I'm of the opinion that we should grow the curl wrapper. Take what is done with python for example: their most famous library ever is requests, and anybody doing networking in python first reaches for it. What is the standard library urllib module for then? Well it's the basis requests is written on, it's meant to provide basic, low-level access to the network, and that's ok. People just learned to use requests. Right now unfortunately the curl wrapper isn't a very good building block to build libraries but by growing it into something with better ranges etc it could be. The critics of the API and memory usage don't need to be: just grow transparently a second facade to the library. No code broken, better tools for better libraries and happier users. The only real point left is managing the C code in phobos but as Andrei said (not in this terms) if Phobos can't do it what good is the "interfacing with C is dead easy" pitch?
Feb 20