webpipes

Hello all - Aside from holding onto the webpipes.org domain, or an occasional maintenance update, I

I had some ideas recently that might make me come back to it soon. On Mon, Dec 8, 2014 at 10:59 AM,

http://apiblueprint.org/ https://helloreverb.com/developers/swagger I'm partial to the work

I haven't looked at it closely, but it sounds like they're just using a REST API to manage

WebPipers, Intro + Vision Greetings! I discovered WebPipes just a few days ago and love the idea. Why

No, but both of those sound like things that I want to know. (I think I could use them on dig.jsondns

I hadn't realized Matt's webpipe.json project included a command line utility. I've

I don't really. I kinda want to be, which is why I made this: https://github.com/progrium/irc-for

Mmm... whenever I talked about joining anything it was done by a block, not the executor. And I don

Cool. I'll ask Joel. I don't think we need to add everyone to the Github org since we've

Just shot he/she/them an email. Doesn't look actively maintained but I'll let you know if I

( s/found/founder/ ) I wrote up an example for the parse markdown block, here's the resulting

Thanks! Any opinions on the block definition API syntax? I'm thinking about leaving both in there

The Minify CSS Action Block is now available. I know it's not exactly the most in demand block

I guess we assumed no nested data, but maybe it's just that you can't key off nested data. So

This repo is now webpipes.github.com and utilizes GitHub Pages under the hood to allow for instant

Hey, I think if you create a repo called webpipes.github.com you can use GitHub Pages ... you just

It would be good to have both, really. Don't know which approach is higher priority though.

Just for reference, these guys have been around for a while: http://tarpipe.com/ If I recall, like

Works similarly to my original version since the output is in the response body. I do dig their

Yeah, you're right it's probably not an issue for us. But it's good practice to do it in

Well you might not have to make that differentiation if it "just works". Let's try it

Yeah. I like it for how well it seems to model most REST APIs. But as you can see, it's not as

I understand the difference, I just don't think we really need different formats. In both cases