Recent content by Sander Postma

  1. Sander Postma

    Live feed API status

    I have attached a fully rendered (auto-generated) UML of the protobuffer model. (Open & zoom)
  2. Sander Postma

    Live feed API status

    We are ready for beta testing as soon as the pull-request for FD-1150 is merged into the release. The settings changed slightly, and they are in the README.md in the events subdirectory https://github.com/bi-foundation/factomd/tree/FD-1150_live_api/events All related projects are in sync on the...
  3. Sander Postma

    Live feed API status

    We are going to review/update some of the field names tomorrow or the day after. I will make sure the next one is complete.
  4. Sander Postma

    Live feed API status

    The live feed API is still in incubation stage but especially the live event export feature from factomd is functional. Work is being done in a fork branch: https://github.com/bi-foundation/factomd/tree/FD-1150_live_api_20190910 ('ve tagged it because we're still working on that branch) The...
  5. Sander Postma

    Factom Live API considerations

    Okay, at this point I have implemented the following event sources: COMMIT_DIRECTORY_BLOCK ADD_TO_HOLDING DROP_FROM_HOLDING ADD_TO_PROCESSLIST (emitted only if all acceptance checks were successful) NODE_INFO NODE_ERROR The first block applies to process messages of which I have...
  6. Sander Postma

    Factom Live API considerations

    I would prefer to make it consistent, not one thing json and the other thing binary. I will create an experimental setup and tests some serialization protocols to see what the impact is and how easy it is to work with them.
  7. Sander Postma

    Factom Live API considerations

    Ok so translate the messages into something more structured. Were you thinking JSON? Protocol buffers?
  8. Sander Postma

    Factom Live API considerations

    Clear, we should have a separate tcp channel for the event listener then. So I think we could use an extra send command in p2proxy after p2p.BlockFreeChannelSend() to another channel to the event listener. (I guess we won't be needing the directed messages.) For the pending entries we can send...
  9. Sander Postma

    Factom Live API considerations

    I've been looking into the code and thinking about this a bit. There already is a lot of code for marshalling and transporting messages in parcels/FactomMessage and I'm looking at what could be reused instead of writing new network transport code. I'd like to explore the following idea first: We...
  10. Sander Postma

    Factom Live API considerations

    I've drafted an illustration based on the functionality where • The API can be used by a static back-end service that always wants to listen for the same events using the same filter. • The API can be used by front-end browser based application that wants to listen for events based who the...
  11. Sander Postma

    Factom Live API considerations

    Yes, the goal is to minimize the impact on factomd. We (BI Foundation) will focus more on the second layer where the new functionality will be incubated. factomd just needs to get all the metrics out, nothing more. Yes we have, but (a more detailed explanation of the first question) - This is...
  12. Sander Postma

    Factom Live API considerations

    1st layer Push process list implementation - As place of event trigger I was looking at stateConsensus.FollowerExecuteDBState around s.AddDBState. However if someone has a better idea please feel free to comment. - The push should contain a signed process list to avoid a man in the middle...
  13. Sander Postma

    Some thoughts on refactoring on the road to sharding

    Hi, We at blockchain-innovation.org are currently working to get up to speed with the code and the protocol to be able to give a hand with the refactoring plans. From what I understand one of the main goals is for the system to become more scalable and to be able to do that the code needs to be...
Top