Feature/stream sift validation

[sssyed]

Updated the kefir demo with comments, slightly better output and new sample data. I'd like to write slightly more descriptive comments for the other examples when I get a chance.

[jasonkuhrt]

Yay!

Can you specify which issues this PR will close. Since the topic is about examples now instead of validation as the branch and title suggest lets update that too. I think to update the branch name would mean a new PR so lets leave that be this time.

[jasonkuhrt]

@sssyed You need to rebase master into your branch so this PR can be merged.

[jasonkuhrt]

@sssyed Rebasing will rewrite your history, if that proves to be a pain you can merge master in although that will show up as a commit which is sort of a shame.

[sssyed]

Apologize for the code rot and if I have enough time this week I'll push the remaining changes. I do feel like these examples would have helped @stresslimit out when debugging input. One quick suggestion @jasonkuhrt, I was wondering if it would OK to change some of the examples in the README from
{ input: { percent: { $gt: 9 } } } to { percent : { $gte : 9 } } ( the latter works on production as opposed to the former)

[jasonkuhrt]

@sssyed The Readme examples are accurate to their relative source which is the directly most important thing for these examples. If we want to use { percent : { $gte : 9 } } then we should reflect that change in the source too.

The confusion lies in pattern matching events that keep the event type out of band. Actually it turns out that this is not true, _we do keep the event type in band_ e.g.:

type: xxx
...

But basically we sketched a different approach with the v3 api where events would be pattern matched like so:

<event-type>: <pattern>
<event-type>: <pattern>
<event-type>: <pattern>
...

// Patterns...
{ percent: { $gt: 9 } }
{ foo: { $in: ['a', 'b', 'c'] } }
...

This is actually completely arbitrary. We could completely rely on SS like so:

pattern: <pattern>

{ $or: [
  { type: 'input', percent: { $gt: 9 } }
  { type: 'bar', foo: { $in: [ 'a', 'b', 'c' ] } }
] }

I categorize this issue as a "bootstrapping"-like problem. How do you elegantly specify different patterns for different events? I think this is a really important touch-point in the API and its not something we've actually invested enough effort into relative its importance yet. With SS we have a really great language (I think) to express ourselves with but there's still a gap about how to "apply it". If we do choose to collectively review the situation I suggest doing so in another forum since this repo is SS specific and now I've ventured into littleBits-specific API issues.

Does my hesitation about simply changing the Readme make sense? I'm expressing the feeling that its a symptom of a larger problem.

[sssyed]

@jasonkuhrt totally makes sense! I see that the problem is a bit domain specific for SS to address.

[jasonkuhrt]

@sssyed Cool. But yeah, definitely think the larger issue mentioned needs a round of review before v3 becomes official/stable. Looking forward to doing that with you!