for-GET HTTP

Help build an alternative generation of HTTP software.
Ej7t66vynaak3jod2scu
Andrei Neculau
Technology
Stockholm
Sweden
1 Team Member

My name is Andrei Neculau.

For the last 2.5 years, I've had the privilege to be in two exciting projects with challenging HTTP APIs. APIs that I eventually designed. The tip of the iceberg is public.

In retrospect, the mass of the iceberg would have ~15% support when it comes down to implementing it in most programming languages and libraries, although the iceberg is 100% following Internet standards.

Contrary to a common perception, the specification of HTTP is not easy, but it's simple. It's modern, flexible, agnostic. It's extremely powerful. The specification is not the problem, albeit not perfect. Nothing is. But the implementation of HTTP on the other hand is almost without exception far from the specification and not using it at its full potential.

My goal is to build an alternative generation of HTTP software that makes use of existing technology and sane software development.

I've been reading up and breaking up the design of an HTTP server, spending the equivalent of every single weekend for the past year, around 2-3 full time months. It's not rocket science at all, but I didn't want to make any compromises regarding the small, important but tricky details.

Over the last year, you might have heard of some of those details, specifically Know your HTTP well, or the HTTP Decision Diagram.

I reckon I need the same time to fill in the gaps and smoothen out the rough corners. What's to come is less of a challenge for me, but I feel it's my duty to go on. So here I am, asking for your support to continue this work without cutting corners and not end up with yet another HTTP hack.

In detail

Today HTTP implementations are

  • severely limited in comparison to the whole specification
  • opinionated
  • prematurely optimized
  • offering little to no redundancy across implementations in the same or different programming languages
  • using naïvely and manually coded parsers
  • inviting software engineers to design and code poor solutions
  • inviting too many software engineers to read and reimplement standards

When I say "HTTP implementations", without pointing out specific libraries, I'm not trying to be elusive at all. I have looked under the hood of existing implementations only to discover the same thing over and over again, with few exceptions. You can just look under the hood of your HTTP parser/server/framework and judge for yourself.

What I envision can be summarized by

  • HTTP implementations that are close to 100% compliant with the spec, yet
  • agile and flexible data-driven implementations, with
  • high redundancy thanks to language-agnostic grammars, state machines and tests, with
  • little HTTP specific code, and thus
  • extremely portable across programming languages and even across other protocols

This vision requires effort and dedication medium term, from more than just one person.

But even if it's just one man, and the goal of this campaign is barely reached, in one year from now, I'll be more than happy to have ticked these checkboxes with regard to HTTP and most common related standards:

  • grammars (PEG)
  • language-agnostic tests (JSON) for grammar parsers and generators
  • language-agnostic tests (JSON) for specific functionality (e.g. content negotiation)
  • state machines (COSMOGOL&JSON)
  • visual debugger
  • functional server instance

Except for the functional server instance, everything will be documented and production ready. You will have lots of quality grammars, test data and a state machine to stop you from thinking of all the HTTP corner cases, headers and status codes. The server and all of the CoffeeScript code will be fully functional, with clean code, but I am not driven to compare its performance with other HTTP 15% servers you might run in your NodeJS production environment today.

Will this help me, if I need to...

  • parse an HTTP message? ✓ YES! into a JSON object (AST)
  • generate an HTTP message? ✓ YES! from a JSON object (AST)
  • test if a HTTP header is valid? ✓ YES!
  • test if my current HTTP server produces valid HTTP messages? ✓ YES!
  • test if my own parser can work with a valid HTTP header? ✓ YES!
  • test if an URI is valid? ✓ YES!
  • use the HTTP decision diagram for a middleware? ✓ YES!
  • use my own simplified HTTP decision diagram? ✓ YES!
  • run an HTTP server? ✓ YES!
  • ... most probably ✓ YES! if you do something connected in any way to the world of HTTP

for-GET HTTP is a collection of software libraries that put together is:

  • ✓ functional - it will run an HTTP server
  • ✓ complete - it will follow and understand 100% of HTTP specification
  • ✓ reliable - it will have functional tests, and the parser uses the grammar the specification comes with
  • ✓ redundant - it will be replaceable with another implementation that works on the same data (grammar, tests, state machine)
  • ✓ efficient - it is KISS and DRY across programming langauges

Why are you looking for crowdfunding?

I am primarily looking for a like-minded crowd who understands the problem and the proposed solution. A crowd that may even want to contribute with code, tests, documentation, anything! If you are not in this crowd, you can still help by sharing this campaign and purchasing "perks". If you think this is nonsense or there is something better already, then speak up and stop me.

Why are you looking for funds?

I have been thinking and coding on this project for a year now, acummulating at least 2-3 man-months of spare time. That's almost all of my weekends. I estimate I've reached half of the journey. That's part of the reason.

Software that doesn't serve a business goal today is usually left to people to code in their 120% time and copyrighted by the company, or, if we're lucky, in their spare time, for free, as opensource. There are around 18 million software developers worldwide. You would think that there should be at least one that gets paid for thinking how the software that runs all of our websites and APIs should look like, and how it can be simplified over and over again, so that it is possible to do more and more things.

This is a not an easy journey, and I don't think this is a one-man job either. Far from. I might also not be the perfect man for the job. I am on the other hand blindly hoping that some "angel" resonates with the importance of a qualitative and simple software in the area of Internet communications and funds a team. I'd love to be in that team on a daily basis!

Otherwise I am looking for penny funds to at least cover some of the invested spare time and energy, time away from family, books and the world, some coffee and beer, useful tools and services, and above all possibilities to meet with like-minded people.

I am biased, but this is a meticulous project which is worth pursuing.

What's in it for me?

I hope to be able to give you back something more than just this software design, data and running code.

For starters, I'll do a quarterly video and email report so that you can keep track of the progress. I'll also have at least 4 premium screencasts showing off the major components of the for-GET machinery.

Some campaign perks will make you a sponsor of this project or major parts of it that you are interested in, and I'll make sure the world knows it!

If you're a company and you want to show interest and support for this project, some larger perks will put you on the front page!

I'll also be more than happy to have a private talk or video conference with your engineers, if you want to make use of the for-GET machinery ASAP, or just make use of my experience.

Whatever perk you choose, all of you have my utmost appreciation. Thank you!

If you have specific perks in mind that are not listed, just ping me and we'll talk.

If you can't contribute to this campaign financially, you can still make a difference! Tell your friends, make some noise, or just ask questions!

I have a question!

I'm sure you do! This is a broad problem domain with high level abstractions and concepts. It's hard to put it all a video or two, and a page worth of text. While the campaign is running, I will come back with more details and also answer questions that I get from you.

Talks and articles on the topic

High-level "rant" (it's not)
presenting for-GET HTTP at Nordic APIs by Andrei Neculau

HTTP is not big, nor healthy. It's hell no!

Man overboard

PEG
"Static Meta Programming" by Patrick Dubroy, Google

State machine for an Erlang HTTP server
"Webmachine: Focus on Resources" by Sean Cribbs, Basho

Why state machines for protocols?
"Webmachine vs Grape" by Sean Cribbs, Basho

Symbolic state of HTTP software today
"Sigh... by James Snell, IBM, and the follow-up

Simple made easy or
Design, Composition, Performance
by Rich Hickey

$90USD
raised by 3 people in 1 month
0% funded
0 time left
$30,000 USD goal
Fixed Funding This campaign did not meet its $30,000USD funding goal by the deadline.
Campaign Closed
This campaign ended on December 1, 2013
Select a Perk
  • $30USD
    Featured
    Support

    Your name will be on the wall of supporters for every repository of this project. All of the above supporter perks

    0 claimed

  • $10USD
    Support PEG grammars

    Your name will be on the wall of supporters for every repository of this project related to PEG grammars. But please remember that the whole is greater than the sum of its parts, so consider supporting the whole project.

    0 claimed

  • $10USD
    Support FSM (HTTPDD)

    Your name will be on the wall of supporters for the HTTP Decision Diagram repository, the state machine that encodes the cortex of HTTP. But please remember that the whole is greater than the sum of its parts, so consider supporting the whole project.

    0 claimed

  • $10USD
    Support test data

    Your name will be on the wall of supporters for every repository of this project related to test data. But please remember that the whole is greater than the sum of its parts, so consider supporting the whole project.

    0 claimed

  • $50USD
    Support + report

    Receive a quarterly video and email report on the progress of this project. + the above supporter perks

    0 claimed

  • $75USD
    Support + report + screencasts

    Get access to 4+ premium screencasts on the advantages of major components of this project. + the above supporter perks

    0 claimed

  • $100USD
    Sponsor

    Your company name will be added to every repository/post of this project.

    0 out of 50 claimed

  • $500USD
    Sponsor + Logo

    Your company logo will be added to every repository/video of this project, to be displayed for the whole of 2014. + the above sponsor perks

    0 out of 10 claimed

  • $1,000USD
    Sponsor + Logo + 2x2h Hangouts

    Questions about HTTP or APIs? I'll try to answer them as best as I can in 2 Hangouts. + the above sponsor perks

    0 out of 10 claimed

Do you think this campaign contains prohibited content? Let us know.