3 ms·

> You are extremely confused at which level it is beneficial to merge projects. Not really, since if you read my comments I suggested they could have been mer

> You are extremely confused at which level it is beneficial to merge projects. Not really, since if you read my comments I suggested they could have been merged into cURL three years ago (after starting four years ago). It wouldn't even be a new project, it would simply be an add-on tool. And that's the point.

dimino 10y ago
Can you restate your thesis? Is is that HTTPie should be merged into the cURL project?
- peterwwillis 10y ago
  > they could have been merged into cURL three years ago (after starting four years ago) > If this was implemented with libcurl and bundled with cURL > httpie gains a wealth of advantages > along with greater support, developer base, test coverage, user base, and lower tco > and cURL gets syntax highlighting
  - dimino 10y ago
    Doesn't this assume the maintainers of both projects would be amenable to such a thing, and otherwise be perfectly in unison with regard to vision and goals?
    - peterwwillis 10y ago
      Actually, it mainly just assumes the author knows C. If they had they could have simply taken cURL and written some wrapper functions to do the JSON query part and the syntax highlighting, then submitted their modifications. No extra project needed, no grand vision required.
      - dimino 10y ago
        Well no, it assumes what I said, what you said, and a bunch of other things. Why are you being weirdly insistent that there only exist exactly one tool for making HTTP requests on the command line?
        peterwwillis 10y ago
        > Why are you being weirdly insistent that there only exist exactly one tool for making HTTP requests on the command line? I'm not. I'm being weirdly insistent that adding features to one good tool is better than having 10 kinda-ok tools all with different features. Imagine if VLC or MPlayer was actually 10 different video players, all of which supported different media formats and had different features. That was actually somewhat the case for a while; kplayer supported some things, the five different GTK/Gnome players supported some things, they were all relatively buggy and playing video was always annoying. Except for VLC and MPlayer, which just did everything, and were mostly fantastic. How did VLC and MPlayer do this? They designed their apps specifically so that they could expand in features, and allowed people to contribute new technology. They supported runtime codecs and extensions. And they had a large development and user base, and people saw the benefit in having one tool that supported as many ways possible of doing the one thing they wanted: playing a video. Having one tool to handle all the weird uses of HTTP may not be reasonable, but having a toolkit that bundles all the weird uses of HTTP would be infinitely more useful than having to download 100 different projects just to munge HTTP requests. There are many such toolkits for other technologies. This is not a new or contentious idea.
        dimino 10y ago
        Not only is this a contentious idea, it's positively absurd on its face. Your logic dictates that every tool with similar goals cannot be maintained separately, and that a single person or group should hold a complete monopoly on how we do any given thing in computing. VLC and MPlayer were two of "10 different video players" when they were made, and a great many other video players, some significantly older and with higher support, were eventually supplanted by them (at least VLC, anywway). In your little model here, that would never have happened. You'd utterly kill innovation and progress with this. I cannot overstate how mistaken you are here, it is completely and wholly a terrible idea, at every turn. Maybe there's something I'm not getting, I certainly hope so.

dimino 10y ago

Can you restate your thesis? Is is that HTTPie should be merged into the cURL project?

peterwwillis 10y ago
> they could have been merged into cURL three years ago (after starting four years ago) > If this was implemented with libcurl and bundled with cURL > httpie gains a wealth of advantages > along with greater support, developer base, test coverage, user base, and lower tco > and cURL gets syntax highlighting
- dimino 10y ago
  Doesn't this assume the maintainers of both projects would be amenable to such a thing, and otherwise be perfectly in unison with regard to vision and goals?
  - peterwwillis 10y ago
    Actually, it mainly just assumes the author knows C. If they had they could have simply taken cURL and written some wrapper functions to do the JSON query part and the syntax highlighting, then submitted their modifications. No extra project needed, no grand vision required.
    - dimino 10y ago
      Well no, it assumes what I said, what you said, and a bunch of other things. Why are you being weirdly insistent that there only exist exactly one tool for making HTTP requests on the command line?
      - peterwwillis 10y ago
        > Why are you being weirdly insistent that there only exist exactly one tool for making HTTP requests on the command line? I'm not. I'm being weirdly insistent that adding features to one good tool is better than having 10 kinda-ok tools all with different features. Imagine if VLC or MPlayer was actually 10 different video players, all of which supported different media formats and had different features. That was actually somewhat the case for a while; kplayer supported some things, the five different GTK/Gnome players supported some things, they were all relatively buggy and playing video was always annoying. Except for VLC and MPlayer, which just did everything, and were mostly fantastic. How did VLC and MPlayer do this? They designed their apps specifically so that they could expand in features, and allowed people to contribute new technology. They supported runtime codecs and extensions. And they had a large development and user base, and people saw the benefit in having one tool that supported as many ways possible of doing the one thing they wanted: playing a video. Having one tool to handle all the weird uses of HTTP may not be reasonable, but having a toolkit that bundles all the weird uses of HTTP would be infinitely more useful than having to download 100 different projects just to munge HTTP requests. There are many such toolkits for other technologies. This is not a new or contentious idea.
        dimino 10y ago
        Not only is this a contentious idea, it's positively absurd on its face. Your logic dictates that every tool with similar goals cannot be maintained separately, and that a single person or group should hold a complete monopoly on how we do any given thing in computing. VLC and MPlayer were two of "10 different video players" when they were made, and a great many other video players, some significantly older and with higher support, were eventually supplanted by them (at least VLC, anywway). In your little model here, that would never have happened. You'd utterly kill innovation and progress with this. I cannot overstate how mistaken you are here, it is completely and wholly a terrible idea, at every turn. Maybe there's something I'm not getting, I certainly hope so.