Re: The end of curl (in phobos)

[Cym13 via Digitalmars-d]

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?

Re: The end of curl (in phobos)

[Gavin via Digitalmars-d]

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?

Re: The end of curl (in phobos)

[Matthias Klumpp via Digitalmars-d]

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

Re: The end of curl (in phobos)

[Chris Wright via Digitalmars-d]

On Sat, 18 Feb 2017 21:41:51 +, 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.

Re: The end of curl (in phobos)

[Seb via Digitalmars-d]

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/phexetutyelrssyru...@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)

Re: The end of curl (in phobos)

[Dmitry Olshansky via Digitalmars-d]

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

Re: The end of curl (in phobos)

[ketmar via Digitalmars-d]

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.

Re: The end of curl (in phobos)

[Seb via Digitalmars-d]

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/odbddahgxadkffbwc...@forum.dlang.org

Re: The end of curl (in phobos)

[Johannes Pfau via Digitalmars-d]

Am Sun, 8 May 2016 11:33:07 +0300
schrieb Andrei Alexandrescu :

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

Re: The end of curl (in phobos)

[Jonathan M Davis via Digitalmars-d]

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

Re: The end of curl (in phobos)

[Vladimir Panteleev via Digitalmars-d]

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.

Re: The end of curl (in phobos)

[Vladimir Panteleev via Digitalmars-d]

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.

Re: The end of curl (in phobos)

[krzaq via Digitalmars-d]

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.

Re: The end of curl (in phobos)

[krzaq via Digitalmars-d]

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".

Re: The end of curl (in phobos)

[ZombineDev via Digitalmars-d]

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.



...

Re: The end of curl (in phobos)

[Jonathan M Davis via Digitalmars-d]

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

Re: The end of curl (in phobos)

[Vladimir Panteleev via Digitalmars-d]

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.

Re: The end of curl (in phobos)

[sigod via Digitalmars-d]

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

Re: The end of curl (in phobos)

[Jonathan M Davis via Digitalmars-d]

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 

Re: The end of curl (in phobos)

[Lionello Lunesu via Digitalmars-d]

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!

Re: The end of curl (in phobos)

[Andrei Alexandrescu via Digitalmars-d]

On 5/8/16 5:37 PM, Suliman wrote:

Andrei, is there any plans to drop etc.c.odbc ?


No. -- Andrei

Re: The end of curl (in phobos)

[Vladimir Panteleev via Digitalmars-d]

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).

Re: The end of curl (in phobos)

[Steven Schveighoffer via Digitalmars-d]

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

Re: The end of curl (in phobos)

[Andrei Alexandrescu via Digitalmars-d]

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

Re: The end of curl (in phobos)

[Jonathan M Davis via Digitalmars-d]

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

Re: The end of curl (in phobos)

[ikod via Digitalmars-d]

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

Re: The end of curl (in phobos)

[Walter Bright via Digitalmars-d]

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.

Re: The end of curl (in phobos)

[Adam D. Ruppe via Digitalmars-d]

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.

Re: The end of curl (in phobos)

[yawniek via Digitalmars-d]

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?

Re: The end of curl (in phobos)

[Jonas Drewsen via Digitalmars-d]

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.

Re: The end of curl (in phobos)

[Suliman via Digitalmars-d]

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.

Re: The end of curl (in phobos)

[Steven Schveighoffer via Digitalmars-d]

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

Re: The end of curl (in phobos)

[Andrei Alexandrescu via Digitalmars-d]

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

Re: The end of curl (in phobos)

[ikod via Digitalmars-d]

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?

Re: The end of curl (in phobos)

[Lutger Blijdestijn via Digitalmars-d]

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.

Re: The end of curl (in phobos)

[Kagamin via Digitalmars-d]

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?

Re: The end of curl (in phobos)

[Jonathan M Davis via Digitalmars-d]

On Fri, 06 May 2016 13:25:55 +
"Adam D. Ruppe via Digitalmars-d"  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

Re: The end of curl (in phobos)

[Adam D. Ruppe via Digitalmars-d]

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.

Re: The end of curl (in phobos)

[Jonathan M Davis via Digitalmars-d]

On Fri, 06 May 2016 08:32:03 +
Robert burner Schadek via Digitalmars-d 
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

Re: The end of curl (in phobos)

[qznc via Digitalmars-d]

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?

Re: The end of curl (in phobos)

[yawniek via Digitalmars-d]

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?

Re: The end of curl (in phobos)

[Dicebot via Digitalmars-d]

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.

Re: The end of curl (in phobos)

[Kagamin via Digitalmars-d]

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?

Re: The end of curl (in phobos)

[Dsby via Digitalmars-d]

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.

Re: The end of curl (in phobos)

[Dicebot via Digitalmars-d]

On 05/06/2016 11:24 AM, Steven Schveighoffer wrote:
> So push dates to 2026-2028 then? ;)
> 
> -Steve

D3 will fix EVERYTHING

Re: The end of curl (in phobos)

[Steven Schveighoffer via Digitalmars-d]

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

Re: The end of curl (in phobos)

[Steven Schveighoffer via Digitalmars-d]

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

Re: The end of curl (in phobos)

[Robert burner Schadek via Digitalmars-d]

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

Re: The end of curl (in phobos)

[Andrei Alexandrescu via Digitalmars-d]

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

Re: The end of curl (in phobos)

[deadalnix via Digitalmars-d]

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

Re: The end of curl (in phobos)

[Dicebot via Digitalmars-d]

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.

Re: The end of curl (in phobos)

[Robert burner Schadek via Digitalmars-d]

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.

Re: The end of curl (in phobos)

[Andrea Fontana via Digitalmars-d]

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

Re: The end of curl (in phobos)

[Johannes Pfau via Digitalmars-d]

Am Fri, 06 May 2016 08:32:03 +
schrieb Robert burner Schadek :

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