Grote lijnen
============

Een collaborative challenge waarin de teams samenwerken om zo veel
mogelijk challenges te completen waarvoor ze specifieke features nodig
hebben in hun HTTP-clients en -servers. Wij hebben op voorhand een
server geconfigureerd die de huidige stand van zaken bijhoudt, en waarop
challenges ingediend kunnen worden (zie verder). Vanaf bepaalde
thresholds bereikt worden, zouden er rewards tegenover staan.

Conceptuele aandachtspunten
===========================

-   Er moet een grote voorstelling zijn van de progress-bar die ergens
    > publiek zichtbaar is. Dit kan zowel op de gebruikte server/site,
    > als hardware-matig (meer werk) (denk een opvullende meetbuis).

-   Het moet makkelijk te zien zijn hoe de challenges origineel verdeeld
    > zijn onder de teams, en welke challenges al voltooid zijn, dit om
    > toe te laten sterke teams meer werk op te nemen, en te vermijden
    > dat zwakke teams in de problemen komen. Maw, de hoeveelheid op te
    > nemen werk is veel dynamischer.

-   Alle rewards horen groepsgebonden te zijn, dit om te vermijden dat
    > er om de 'makkelijke' challenges gevochten wordt.

-   De challenges horen klein en modulair te zijn, zodat makkelijk
    > incrementeel gewerkt kan worden, en de instapdrempel verlaagd
    > wordt.

Server-eigenschappen
====================

Strakke interfaces zijn leuk en professioneel. Zoals reeds vermeld is
een grote focus op de vooruitgang van het geheel. Verder is er een
duidelijk overzicht nodig van de challenge-statussen (ASSIGNED TO,
COMPLETED, BUSY, REQUESTED, ...). Dit is ons MVP, en kan in principe
heel simplistisch geïmplementeerd worden (desnoods met publieke
spreadsheets) en een progress bar site. Een kleine dedicated server zou
echter wel op zijn plaats zijn.

Verder moet de server ook een aantal triggers proccen als er bepaalde
requests naar toe gestuurd worden, dit zouden dan de challenges zijn, en
de meter omhoog doen gaan. Om ook server-related uitdagingen te hebben
zou de server met speciale requests kunnen pollen op enkele ip-adressen
die dan online zouden kunnen worden ingegeven.

Challenges
==========

Kleine, losstaande uitdagingen die een bepaald aspect van het HTTP
protocol zouden moeten verkennen. Voor concrete ideeën moet ik mijzelf
wat verdiepen in de HTTP-specs, maar er lijken mogelijkheden genoeg te
zijn. Voorbeeld: laat je client een request sturen waarin een bepaalde
image zit.

TODO: Challenges oplijsten

Gegeven:

-   De HTTP-specs

-   Een lijst van wijzigingen aan de URL- en HTTP-specs naar het
    > Pizza-protocol

    -   Dit om te vermijden dat bestaande libs gebruikt worden

    -   Bv: in plaats van GET doen we ORDER

    -   Bv: in plaats van http://example.org/bla\#foo wordt het
        > 🍕:org.example🍴bla🍝foo

<!-- -->

-   Een start-URL

Toegestaan:

-   TCP-library

-   DNS-library

Verboden:

-   URL-library

-   HTTP-library

Ruben's quick ideas (in opklimmende moeilijkheid):

-   TCP-connectie maken met het IP-adres op poort 80

-   Eerste requestregel correct (GET /)

-   Request met Host: header correct

-   Meerdere headers meesturen

-   Parsen van de response headers

-   Parsen van de response body

-   Een POST request sturen

-   Een gegzipte response body ontvangen

-   Een gegzipt POST request opstellen

-   Meerdere requests over een enkele connectie sturen

-   Een koffie bestellen als dessert
    > ([[https://tools.ietf.org/html/rfc2324]{.underline}](https://tools.ietf.org/html/rfc2324))

-   ...en tot slot, enkel als al het bovenstaande werkt: een gewoon
    > HTTP-request met dezelfde client (maar nog steeds de pizza-URL, om
    > valsspelen tegen te gaan).

Rewards
=======

TODO