On 2013-11-27 20:13, Dicebot wrote:

> DVM is already broken if it relies on binaries present in .zip
> We can't claim that we support things that we don't actually support

It works perfectly fine on Mac OS X and Windows. No need to break it on all platforms just because one platform is broken. I haven't had any problems on Linux either.

-- 
/Jacob Carlborg

On 2013-11-27 19:58, Andrei Alexandrescu wrote:

> Wait, you mean with binaries and all?

I mean that I like the current zip to stay.

-- 
/Jacob Carlborg

On Wednesday, 27 November 2013 at 20:05:29 UTC, Jacob Carlborg wrote:
> On 2013-11-27 20:13, Dicebot wrote:
>
>> DVM is already broken if it relies on binaries present in .zip
>> We can't claim that we support things that we don't actually support
>
> So we don't support the zip we release every time?

Yes, this is exactly the very reason of this thread. Don't support and have never really supported. It does support Debian-based stuff and some other distros may happen to work so there were no real fuss about it. Does not make it less broken thugh.

On Wednesday, 27 November 2013 at 20:06:52 UTC, Jacob Carlborg wrote:
> On 2013-11-27 20:13, Dicebot wrote:
>
>> DVM is already broken if it relies on binaries present in .zip
>> We can't claim that we support things that we don't actually support
>
> It works perfectly fine on Mac OS X and Windows. No need to break it on all platforms just because one platform is broken. I haven't had any problems on Linux either.

Distributing binaries for Mac and Windows is fine (though it is much better to keep those separate archives and patch DVM accordingly), this thread is about Linux ones. You did not have any problems with it because Debian derivatives take major percentage of users and you are likely to have one.

On Wednesday, 27 November 2013 at 14:16:33 UTC, Adam D. Ruppe wrote:
> (The biggest pain with clients btw? Buggy servers! It has gotten a little better, but when I started with this, Twitter, LinkedIn, and AWeber, the three I had to use.... all interpreted the spec slightly differently, so what worked on one wouldn't work on the other two, and, of course, the error messages are  never helpful and the documentation sucks. Massive pain.)

Because they started using oauth 2.0 when rfc draft changes every day. I remember the pain. Now it seems that there's a final rfc. I remember that google implemented draft #xx twitter draft #yy and so on...

On 26.11.2013 20:01, Andrei Alexandrescu wrote:
>> I'm for removing as I always compile Phobos without curl anyway (I don't want to install all dependencies).
> 
> So then why are you bothered? Are you willing to break a lot of people's code because you don't need this feature?

I'm not that bothered really, not a major point for me. Just seems more flexible having the curl wrapper as an independent library. Or some system for enabling/disabling components (assuming other wrappers will be added in the future).

-- 
mk

On 2013-11-27 21:46, Dicebot wrote:

> Distributing binaries for Mac and Windows is fine (though it is much
> better to keep those separate archives and patch DVM accordingly), this
> thread is about Linux ones. You did not have any problems with it
> because Debian derivatives take major percentage of users and you are
> likely to have one.

If we're removing the zip as it currently is, it's another prof that D isn't stable as it claims to be.

And I repeat, why should we break for every platform when it's only one platform that is broken.

-- 
/Jacob Carlborg

On Wednesday, 27 November 2013 at 01:32:18 UTC, Jonathan M Davis wrote:
> On Wednesday, November 27, 2013 02:05:39 Adam D. Ruppe wrote:
>> ...unless doing a new interface is on the table too. Then, we can
>> leave std.net.curl exactly how it is, so people who use it don't
>> have broken code, while a new std.net.http, std.net.smtp,
>> std.net.ftp, and so on are phased in for people who want them. I
>> could get behind that.
>
> If we were going to replace std.net.curl, I would fully expect us to end up
> with a new API, because the current API is what is beacuse of what curl can
> and can't do rather than because it's the best API for what you're
> conceptually trying to do. The new API might end up being fairly close to the
> current one, but I would not consider it desirable to try and maintain a 100%
> compatible API if we were replacing the current implementation except in cases
> where the current API is the best choice even without curl underneath it.
> Maybe that would be most of the API, but I'd hate to see us put ourselves in a
> straightjacket based on how curl works when writing an API which didn't depend
> on curl - particularly as writing our own would give us the opportunity to
> make sure that we had something that made the most conceptual sense rather
> than necessarily having what curl has.

I definitely agree. In addition D has obtained some nice features since the definition of the std.net.curl API that I would liked have used back then.

I do believe that people underestimate the work needed to make a proper http client implementation with the bells and whristles that people expect like cookie store, chuncked transfers, ssl, authentication... and handle wierd per server type bugs as well.

I definitely think that a native solution is the end goal here. But if that is the case then it should be based on a proper event based system (std.event?) to support async handling (peek at how vibe has done it very nicely). But that in turn depends somewhat on allocators being well defined and implemented as I see it.

-Jonas

On Thursday, 28 November 2013 at 07:36:09 UTC, Jacob Carlborg wrote:
> On 2013-11-27 21:46, Dicebot wrote:
>
>> Distributing binaries for Mac and Windows is fine (though it is much
>> better to keep those separate archives and patch DVM accordingly), this
>> thread is about Linux ones. You did not have any problems with it
>> because Debian derivatives take major percentage of users and you are
>> likely to have one.
>
> If we're removing the zip as it currently is, it's another prof that D isn't stable as it claims to be.
>
> And I repeat, why should we break for every platform when it's only one platform that is broken.

We can leave old .zip as-is just make it explicit that it is legacy layout and only 100% expected to work on Debian-compatible distros. I really don't care how it is distributed as I am using git tag anyway - what I do care about are users having wrong expectations when they come to download page.

El 26/11/13 19:44, Andrei Alexandrescu ha escrit:
> On 11/25/13 4:36 PM, Adam D. Ruppe wrote:
>> On Tuesday, 26 November 2013 at 00:13:57 UTC, Andrei Alexandrescu wrote:
>>> First I'd like to gather an understanding on why we seem to have this problem (far as I understand, the likes of php and python are doing fine with curl, but maybe I'm wrong).
>>
>> A major difference is there's only one php/python binary, usually build on the same system that uses it. Phobos, on the other hand, is generally built on the packager's computer, which isn't always binary compatible with the deployment box.
>>
>> On Windows, the problem is simply that curl isn't packaged with dmd, for some weird reason, meaning people have to get curl.lib separately. That's idiotic. But then again, so are a lot of the dmd Windows deficiencies.
> 
> Please let me know whether my understanding of the situation is correct:
> 
> 1. If people have a working installation of libcurl on their machine, we work with it.
> 
> 2. Otherwise, phobos works fine but attempting to use std.net.curl will fail.
> 
> Is this correct? If not, please explain exactly why. If yes, this setup seems entirely appropriate to me.

Point 2. is correct only with phobos static library but not with shared one. A simple "Hello World" program cannot be linked against shared phobos library if libcurl is not available on system, at least on Linux. It cannot run either.

-- 
Jordi Sayol