/PROG/ SUMMER OF CODE

Greetings /prog/ !!

Some of you might be looking for FUN SUMMER PROJECTS[i]!![/i] Here is something you could try to program: let's build a global decentralized persistent "functional" (immutable) data store which works by exchanging messages. These messages could be serialized/stored/communicated however you want (we can always write adapters to have your programs communicate with eachother). But they need to satisfy following semantics:

__________________________________________________________________________________
Two basic messages are supported:

* define a new type of entity
* create a new entity

ENTITY TYPE
* Loosely corresponds to a table
* Has a name
* Has a number of (typed) fields
* Has a number of constrainst for entities.

ENTITY
* Loosely corresponds to a row in a table
* Has an entity type
* Is a mapping of field to value
* Satisfies the constraints from the entity type.

TYPE
* Fields in entity types have a TYPE
* You can not define extra types (although one of the types could be "a reference to an entity ABC which satisfies constraints DEF)
* Types will probably be things like: a unicode string, an ascii string, a number, a list of TYPE, a mapping of TYPE to TYPE, ...

CONSTRAINT
* A given entity satisfies a constraint at the time of creation.
* A constraint should be "positive" (not sure how to describe this). You could have a constraint that says "an entity of type X needs to exist with title = X" but you can NOT have a constraint that says "no entity with type X and property XYZ must exist". A server should be able to reject invalid entities without having access to all entities.
* Examples of constraints:
- list contains elem
- value bigger than value
- signature is valid for public key and data
- ...

(fucking syntax highlighting)
__________________________________________________________________________________

You'll need to design a way to serialize and transport these messages over existing protocols (think: email, IRC, plaintext pipes, HTML5 JSON APIs, soaps and so on). I think we might need a bit more work on the "types" and "constraints" part (perhaps we can steal from some existing system? any academics wanna chime in here?), but then we're good to go.

so itt: how do we represent types & constraints + pledges to implement the system along with what protocol you'll layer over. I'll do a RACKET implementation with a POSTGRES backend and an EMAIL transport.

feel free to bikeshed this to death, but don't let other people stop you from writing history!!

>>4
You typed that message imperatively