@fogine yes, your presumptions are correct. So if a developer wants to extend swagger feature, he has to wait for the private branch to be published. The point of releasing a free version to the public is that I want to keep the free users. And people still can do minor changes like bugfixing. I guess this is a trade-off between the OSS community and commercialization.
Basically, the shifting point is based on whether we have any new features. If I added a new feature, the minor version goes up (such as v0.9.x -> v0.10.0), then the new version will be kept in private. If it just a bugfix or minor change, only the patch version increase (such as v0.9.2 -> v0.9.3), then we don't shift at all, i.e., private is still private, public is still public. However, I may move bugfix from private to public and vice versa. The same rule applies when we have a major version, say v1.0.x. It'll be kept in private first until we have v1.1.0. Regardless, I'm exploring with this early access idea and wanting to find out how it would work.
@eliangcs, The following is my view and thoughts.
By "a free community" expression I mean a group of people activelly interested in a project by participating in the development (with no expectation of financial profit) with anything more than small bug fixes or feature requests.
Personally, I don't think that the current business model is gonna work well with any kind of "free" community as contributors are basically cut off of upstream.
In my opinion, trying to get a free community work with commercialized sector is understandably only gonna get people confused. As you suggested, making a commercialized organization from the product could possibly work.
However, questions raise, whether the product is large enough? Can it produce enough value over time to sustain itself on the market and uphold its price demands?
Maybe it could make the organization more successful if the organization produced other related products along http-prompt...? Have you stumbled upon the Restlet company, @eliangcs?
I see two general approaches which tend to collide when combined.
- Free OSS community where options for any financial profits are limited and not guaranteed (bounties & support via patreon etc)...
Contributors are left to make ends meet aside their work in the OSS or count on voluntary financial supporters. This is the main reason why the OSS development tends to be noticeably slower then commercialized sector as free time of individuals is limited.
The main advantage is that literally everyone (without an exeption) can profit from produced value and everyone is welcomed in the community and has an opportunity to participate in final product. - In comercialized organizations (to any degree), members can afford to spend more time making the final product given a period of time.
Thus the organization produces more value over time (not necessarily of better quality ).
Drawbacks are that the right to profit from produced value (use product) is strictly conditional... it creates user expectation of the organization to produce value.
We can say that to certain degree we splitted OSS community to two groups, a group which produces value and the other one which uses the product.
I'm not even sure if the two approaches can be combined in today's society. I think the roots of the issue are in politics but let's not dive into that.
To answer your question more dirrectly, the current circumstances make me to reprioritize my current and future focus of my contributions in OSS
However it does not preclude me from contributing to http-prompt project as it will depend on how I will be using http-prompt, how much free time will be available and whether I will need some functionality not implemented yet.
if you were interested in more close collaboration, I'd be open to that.
I realize that I've written a lot of stuff you already know but still I hope these insights will be somewhat helpful to you.
@fogine thanks for the feedback! It's really valuable. I agree with you that current business model probably won't work and it retrains the community from growing. So I think I'll change my direction here. Instead of monetizing the core product (http-prompt), we should make another related product based on http-prompt. The related product is probably an SaaS that bring more organization-specific features to http-prompt, similar to what Postman and Insomnia do. Anyway, it's still undecided. In the short term, I would do the following:
- Remove the early access subscription
- Change http-prompt license back to MIT
- Release v0.10.0 publicly
Let me know if you have any other ideas. Thanks!
Hello all. Just found about this command line client. Is there a way to store/list/add/remove/manage a list of presets? Similar somehow to what you can do in Postman. What I mean is something like editing an input file in some format where you can list all your preset REST calls with their own properties. E.g.:
presets: [{
name: 'Load foos - Local machine',
url: 'http://localhost:1234/api/foo',
verb: 'get',
authorization: {
type: 'basic',
username: 'johndoe',
password: 'SECRET PASSWORD',
},
headers: [{
key: 'accept',
value: 'application/json',
}],
}, {
...
}],and then be able to feed one of this presets into http prompt command line: http-prompt --input ./my-presets.conf --preset 'Load foos - Local machine'
env command does. You can export the env output to a file. Then import it with exec or source command. Refer to the doc here: http://docs.http-prompt.com/en/latest/user-guide.html#saving-and-loading-sessions
file.json content
{
"addr0": "Unit 315, 3/f PAK TIN ESTATE, BLOCK 10, Shek Kip Mei",
"reference": "1",
"returnRecords": 10
}
when I run with debug mode , the content is
"data": "{\"field\": \"{\r\n\t\\"addr0\\": \\"Unit 315, 3/f PAK TIN ESTATE, BLOCK 10, Shek Kip Mei\\",\r\n\t\\"reference\\": \\"1\\",\r\n\t\\"returnRecords\\": 10\r\n}\"}",
it seems that , http-prompt add redundant file in the json content "file: {}" . I really dont need it.
source .bash_profile
Hello everyone. It seems for me, that http-prompt somehow ignores Content-Type: application/x-www-form-urlencoded. Even though httpie preview returns the right command
http --form --proxy=https://localhost:9999 --verbose --verify=no http://example.com password=bar username=foo Content-Type:application/x-www-form-urlencodedthe actual request treats the body to be json
http://example.com> post
POST / HTTP/1.1
Accept: application/json, */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 38
Content-Type: application/x-www-form-urlencoded
Host: example.com
User-Agent: HTTPie/2.0.0
{"password": "bar", "username": "foo"}Whereas, when running the httpie command directly on the shell, it's interpreted correctly
$ http --form --proxy=https://localhost:9999 --verbose --verify=no http://example.com password=bar username=foo Content-Type:application/x-www-form-urlencoded
POST / HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 25
Content-Type: application/x-www-form-urlencoded
Host: example.com
User-Agent: HTTPie/2.0.0
password=bar&username=fooHas someone experienced this issue so far as well? Was browsing the reported issue, but couldn't find something related.
Traceback (most recent call last):
File "/home/afropunk/.local/bin/http-prompt", line 7, in <module>
from http_prompt.cli import cli
File "/home/afropunk/.local/lib/python2.7/site-packages/http_prompt/cli.py", line 10, in <module>
from httpie.plugins import FormatterPlugin # noqa, avoid cyclic import
File "/home/afropunk/.local/lib/python2.7/site-packages/httpie/plugins/init.py", line 6, in <module>
from httpie.plugins.base import (
File "/home/afropunk/.local/lib/python2.7/site-packages/httpie/plugins/base.py", line 104
def format_headers(self, headers: str) -> str:
^
SyntaxError: invalid syntax
</code>
Hello !
Trying to send a GET request with digest auth, I get the following error :
❯ http-prompt http://app.example.com:8080
Version: 1.0.0
http://app.example.com:8080> --auth-type digest
http://app.example.com:8080> --auth foo:bar
http://app.example.com:8080> get
usage: http [--json] [--form] [--compress] [--pretty {all,colors,format,none}] [--style STYLE] [--unsorted] [--sorted] [--format-options FORMAT_OPTIONS] [--print WHAT] [--headers] [--body] [--verbose]
[--all] [--history-print WHAT] [--stream] [--output FILE] [--download] [--continue] [--session SESSION_NAME_OR_PATH | --session-read-only SESSION_NAME_OR_PATH] [--auth USER[:PASS]]
[--auth-type {basic,digest}] [--ignore-netrc] [--offline] [--proxy PROTOCOL:PROXY_URL] [--follow] [--max-redirects MAX_REDIRECTS] [--max-headers MAX_HEADERS] [--timeout SECONDS] [--check-status]
[--path-as-is] [--verify VERIFY] [--ssl {ssl2.3,tls1,tls1.1,tls1.2}] [--ciphers CIPHERS] [--cert CERT] [--cert-key CERT_KEY] [--ignore-stdin] [--help] [--version] [--traceback]
[--default-scheme DEFAULT_SCHEME] [--debug]
[METHOD] URL [REQUEST_ITEM [REQUEST_ITEM ...]]
http: error: unrecognized arguments: GET http://app.example.com:8080Any tip is welcome. Thx !
I'm facing a strange behaviour. If i'm running the preview of the call with httpie every thing looks as expected however when I'm running a GET call I'm getting http: error: unrecognized arguments: GET http://localhost:8080/api/test. If i redirect the hole preview to a file or just take it and runit in httpie not on http-prompt I'm getting a result as expected.
What could be wrong. I have to mention that I'm using other parmaters as well (--auth=<encoded jwt token> and ----auth-type=jwt)
Thank you