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.
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.
Today HTTP implementations are
- severely limited in comparison to the whole specification
- 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.
- Raise an issue on Github (all questions will be centralized in the README repository)
- Tweet to #forgethttp @andreineculau
- Leave a comment on Indiegogo
Talks and articles on the topic
High-level "rant" (it's not)
presenting for-GET HTTP at Nordic APIs by Andrei Neculau
"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