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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017