This task was filed through the "New Feature Request" form.
Raw HTTP is actually perfect for me! Thank you!
But if you say "Haskell" you may have to wait a minute.
Maybe easier would be for you to tell me what language you want to use and I'll just write you a snippet which encodes a request?
The page implies that all I should need to do is POST up, for example, the following:
To be clear though, I still haven't figured out how to actually put in a POST body. It's fine to use URL params for something like differential.querydiffs, but I can imagine the problems I'll run into with URL length when doing harbormaster.sendmessage (especially when reporting a bunch of unit test and linting results).
Yeah, there's no real hint about that in the UI to suggest that the box will update, and it's easy to miss since it looks nearly identical after it updates. I'll add a piece of hint text to hopefully make it more clear.
OH, that only happens if you do the human-readable option. I didn't notice that little box at the bottom had changed amidst the giant blob of json that the call returned.
Oh, maybe we could make this more clear. Here's how to use the examples to figure out how to make a call:
The good news though is with that hint I seem to have it working without even needing to POST: https://phabricator.myurl.com/api/differential.querydiffs?api.token=api-TOKEN&ids=5
I can definitely try either of those two options, but to my point, it wasn't obvious to me from the documentation:
(Kicking Documentation off because this would just be another tab next to PHP / cURL / arc in Conduit, not static documentation.)
Can you use a service like https://requestb.in with curl?
Thu, Mar 23
With subprojects, #project changed to mean "that project, and all its descendant projects", but any(...) and not(...) still mean "just the parameter, exactly". I think viewerprojects() and projects(user) are also "just the parameter".
Well we also have a lunch today.
We could probably ship it (.md in Diffusion rendering as GitHub Flavored Markdown) this week -- it wouldn't be perfect, but we do have total freedom there to iterate as we find cases we're missing there -- it's just a pretty hard sell as a priority for me relative to the development cost. Obviously it would be nice if you bring in your repository to Phabricator and the README.md renders perfectly instead of rendering mostly-okay-but-a-bit-buggy, but it's hard for me to imagine we're losing many users there.
Having markdown rendered in documentation as expected probably alleviates 90% of my concerns. At least, having to retype or reformat large chunks of text is un-cool and arduous. Learning some new markup, less so. But it sounds like thats years away.
My anecdote here is Betamax vs. VHS. Yes, one is superior, the other has 95% of the market. I believe we're both right, but weigh certain issues differently. I see the new user coming from GitHub as the more important customer, as it leads to growth. The more things are different in Phabricator, the steeper the climb. You're right from a technical standpoint, and I do believe Remarkup is superior, so I'm stuck.
I think the two goals are sufficiently in conflict and the value of supporting these rules is so low that it probably isn't worth the effort to try to get it right most of the time.
Maybe a different question is, what percentage of block of Remarkup here include code-related discussions. I'm not saying rendering those well shouldn't be a high-priority, I just see Remarkup used for much much more (task discussions, documents, conpherence, etc).
Are you strictly saying both goals here are not attainable?
I can confirm that In Any: does not seem to include subprojects. I tried to make some sense of the way the project search functions work but it's pretty complicated.
My viewpoint is that Markdown was developed for writing first-party blog posts, not for technical discussions about software.
Just going to reopen this as a wishlist item. Italics/Bold here is probably the biggest requests for cross-functionality Remarkup <-> Markdown I'd personally have. And at least in your test cases, it seems even GitHub fails at them (and CommonMark), though Slack does not, so I think these are workable in the general sense, just will likely come with lost of test cases and regex support. I think correctness of expectation is your main concern (and the maintenance cost), not adhering to a "spec"?
@beber, please file a new task with reproduction instructions that work on a clean install if you believe you've found a bug.
Wed, Mar 22
Yeah, we kind of fake that now by offering an index page on Phriction welcome with major projects being there on "root" level.
I think we should just move Phriction to being a full CMS with different top-level hierarchies, which could be space aware. Just implementing Spaces doesn't make much sense otherwise.
No interest from the upstream (we don't take design suggests as feature requests), you are welcome to fork Phabricator to provide these locally if you need.
Tue, Mar 21
Alright chad, from T8783 it seemed like Nuance was still far away, but 3 months doesn't sound that bad.
As suggested I commented on our use case for Nuance. I think we can probably stop annoying @epriestley with that Diff and I'll just patch it on my own installation while Nuance is still in development which is probably easier for all of us.