Updated Client API

[willscott]

Main parts:

• Client makes a topic using NewTopic()
  • Keeping track of sequence number progression isn't done, issue is #25
  • topic.Updates is a channel where new messages can be watched for.
• An update is published to the channel using client.Publish(topic, "message")
• To subscribe, use topic.CreateSubscription() / client.Subscribe(subscription)

Internally, the Client will manage the list of its subscriptions, and act as a RequestGenerator to the RequestManager, where it is queried periodically and selects a read among available subscriptions.

Responses to read requests made by the RequestManager will be sent to the OnResponse handler in Subscription, which decodes them, and sends them to the defined update channel. Work to un-xor the final pair of reads back to the actual cell remains.

[ryscheng]

I think we should separate NewTopic() with Import(serializedTopic)/Export() One involves generating new keys. The other has to do with sharing and existing topic (with some state). Could also be called serialize/deserialize

[ryscheng]

Is there a reason why we need the updates channel when we already have a function for Publish?

[ryscheng]

Open question: Who is responsible for storing the topic state persistently? If it's the application, what's the interface there?

[ryscheng]

Wouldn't mind roughly following something like this: https://godoc.org/cloud.google.com/go/pubsub

In which case, Publish is exposed off of topic, topics are named, and subscriptions are separate.

[willscott]

updates was meant as the place where new changes from a subscription (the output of reads) go to. Publish is where new changes get put into the system.

I imagine the client applications using libpdb will need to store state persistently. A serialize / deserialize interface seems basically right.

Your link looks good. I'll take a look at splitting a 'Topic' which publishes from a 'Subscription' which reads. Part of the complexity is that right now they're both together in the 'Topic' class.

[willscott]

What derived information from a topic is needed for someone to create a subscription to it?

Pubsub uses an iterator as a result of requesting messages from an active subscription. We should just return a channel of messages instead, which is a much more natural go idiom for that.

[willscott]

Please take a look. Have current tests passing again, with a refactored topic and subscription class.

Todo's include

• topic handle & encryption codified with pki
• serialization / deserialization of subscription
• tests for serialization / deserialization of topic
• keeping track of active range of sequence numbers seen. actual sequence number getting encoded by server, but the position of writes within the topic (for ratcheting the seed) to be tracked and updated appropriately in both topics and subscriptions
• understanding the failure case where a topic has been updated so much that an out-of-date subscription no longer knows how to 'catch up'

[willscott]

Resolved the TODO for encryption/authentication of messages.

• A ratchet should be added such that previous signatures become refutable
• Tests for serialization needed

[willscott]

This is at a state that's reasonable for review. I'll hold off on remaining items until we take this chunk and deal with it.

[willscott]

Merged client and request manager, and was able to remove about 150 lines in doing so.

The subscription / polling code isn't finished yet, so added at test for writing, but the pir vectors generated by the read request won't properly xor in the the buckets at this point so it's hard to tell if they are made correctly.

Will try to focus on not adding even more functionality in the PR for now :)