1. 30 Sep, 2015 1 commit
  2. 29 Sep, 2015 2 commits
  3. 15 Sep, 2015 5 commits
  4. 14 Sep, 2015 1 commit
  5. 10 Sep, 2015 1 commit
  6. 09 Sep, 2015 3 commits
  7. 06 Sep, 2015 1 commit
  8. 04 Sep, 2015 3 commits
  9. 03 Sep, 2015 1 commit
  10. 02 Sep, 2015 1 commit
  11. 01 Sep, 2015 1 commit
  12. 31 Aug, 2015 1 commit
  13. 30 Aug, 2015 1 commit
  14. 14 Aug, 2015 2 commits
  15. 08 Aug, 2015 1 commit
  16. 06 Aug, 2015 2 commits
    • Kenton Varda's avatar
      316d7252
    • Kenton Varda's avatar
      WIP JSON encoder/decoder library. Currently only encodes. · e3e9ce8d
      Kenton Varda authored
      The library allows for registering special handlers for specific types or fields. This is particluarly useful for overriding the way `Data` is encoded (since many approaches exist) or supporting encodings like EJSON or Q which extend JSON with special types encoded as objects with field names perfixed by dollar signs.
      
      Not integrated into build system yet (but builds nicely with Ekam). I think this is going to need to be a separate library, e.g. libcapnp-json, because clearly a lot of Cap'n Proto users don't need it at all.
      
      For the moment, this was written for use inside Sandstorm. There is no current need for a decoder, so I have not written that yet and have no immediate plans to do so. But it will be added before any official Cap'n Proto release, certainly. A simple recursive descent parser should be easy...
      e3e9ce8d
  17. 03 Aug, 2015 1 commit
  18. 02 Aug, 2015 1 commit
  19. 31 Jul, 2015 2 commits
  20. 29 Jul, 2015 1 commit
  21. 24 Jul, 2015 1 commit
  22. 23 Jul, 2015 2 commits
    • Kenton Varda's avatar
      Fix link errors. · 96e9663a
      Kenton Varda authored
      96e9663a
    • Kenton Varda's avatar
      Fix bug causing exception: "'Disembargo' of type 'senderLoopback' sent to an… · d4cd01e9
      Kenton Varda authored
      Fix bug causing exception: "'Disembargo' of type 'senderLoopback' sent to an object that does not point back to the sender."
      
      The problem happened when pipelined calls were made on a promised capability, but then that capability turned out to be null. The promise resolving code incorrectly interpreted this as the remote promise having resolved to a local capability (because the "null" stub capability looks local), and so it would send a Disembargo message to flush the pipeline as required. However, the remote end would receive this Disembargo message and find it is addressed to a null capability, not a capability pointing back to the sender. This was treated as a protocol error, causing the receiver to close the connection.
      
      The solution is to explicitly identity "null" capabilities so that we can distinguish this case. This change also has the benefit that now when you copy a null capability between messages with foo.setCap(bar.getCap()), the pointer will be set null in the destination, rather than becoming a reference to a local broken capability.
      
      Thanks to David Renshaw for narrowing this down.
      d4cd01e9
  23. 22 Jul, 2015 1 commit
  24. 17 Jul, 2015 4 commits