I'm syncronizing part of the sawtooth ledger with an external database by subscribing to events 'sawtooth/state-delta' and 'sawtooth/block-commit', so when a Fork accures I have to be able to recognize invalidated transactions as described in the documentation:
https://sawtooth.hyperledger.org/faq/transaction-processing/#how-do-i-handle-forks-while-subscribing-to-sawtooth-events
However, the state-delta events don't have any attribute referencing the block that generated them. The closest I've gotten is by looking at the sawtooth project:
https://github.com/hyperledger-archives/sawtooth-supply-chain.git
In that project is seems that events are grouped in "EventLists", and that if you subscribe to both to 'sawtooth/state-delta' and 'sawtooth/block-commit' events you can tell a delta event corresponds to a block if they are included in the same "EventList". The problem is that the documentation, as far as I can tell, does not guarantee this behavior.
Every list of events with a block-commit event will only have one block-commit event. If an event is on that list it was generated by the block described in the block-commit event.
https://sawtooth.hyperledger.org/docs/core/nightly/1-2/app_developers_guide/zmq_event_subscription.html?highlight=last%20known%20blocks#correlating-events-to-blocks
Related
I had a warning message in Chrome, this one notice that Object.observe method is deprecated and will be removed in Chrome 50 around April 2016.
Have you an alternative solution to replace Object.observe ?
Thanks
So it was depricated and will be removed because of some problem with perfomance. Please see this link http://www.infoq.com/news/2015/11/object-observe-withdrawn
I think you should look into RxJS library and it's Observable
Using RxJS, you can represent multiple asynchronous data streams (that
come from diverse sources, e.g., stock quote, tweets, computer events,
web service requests, etc.), and subscribe to the event stream using
the Observer object. The Observable notifies the subscribed Observer
instance whenever an event occurs.
https://github.com/Reactive-Extensions/RxJS/
In the box docs, it states that the event TAG_ITEM_CREATE occurs when 'A Tag was added to a file or folder'. Is there any way to find out which folder/file the tag was added to ,without iterating them all?
If you're fetching events for a Box enterprise you can have Box perform server-side filtering of events. However, when fetching events for a standard Box account you must do the filtering in your application. The next_stream_position parameter can be used to set a lower time bound for the events that you receive, which can significantly reduce the amount of metadata that you have to sort through.
EDIT: Answering questions from comment.
Q: Not sure how filtering events helps me work out which folder has been tagged?
The event object that's returned to you will look like this:
{
"next_stream_position":1348790499819,
"entries":[
{
"event_type":"TAG_ITEM_CREATE",
"source":{
"type":"folder",
"id":"11446498",
... more event info ...
}
},
... more events ...
]
}
In your application you can look for those events whose event_type is TAG_ITEM_CREATE. You can then use the source to determine which particular resource was tagged.
Q: Are you saying that I can ask for all folders changed since a given TAG_ITEM_CREATE event?
No. Think of the 'next_stream_position` property as a proxy for a timestamp. You can use it to tell Box, "Tell me about all the events that occurred after this 'position' in time." But this will still give you all types of events that occurred. You'll have to select the events of interest in your application.
This is one of the big differences in the Enterprise- and User-facing APIs. In an Enterprise you can tell Box, "I want info on all the TAG_ITEM_CREATE events that occurred in the Enterprise between yesterday and today." In the User-facing API the best you can tell Box is effectively, "I want info on all events that occurred in this User's box since yesterday."
In order to get the keyboard state we can listen to "keydown" event but is it possible to interrogate the keyboard without an event? Something like window.keyState.shiftkey?
In 2018 I'm investigating the same thing: (re-)initialisation on acquisition of focus.
Initialisation (determination of system state) is required when the application starts. It is required every time the application recovers focus after losing it to another application, because state like NumLock can change while the application does not have focus.
As the question notes, this information can be obtains from event objects.
There doesn't appear to be any way to request this information.
This requires a change to browsers. In my opinion a low impact solution
for this and parallel situations is a general mechanism for requesting a "null event" of a specified type, eg
var ke = window.requestEvent("keyboard");
var me = window.requestEvent("mouse");
var te = window.requestEvent("haptic");
Since a keyboard/mouse/touch event is not actually occurring, the field that would otherwise quantify the event (key code, mouse position etc) should be null.
This API should not be a breaking change for event handlers, since it doesn't actually trigger an event, it's a function that returns an event object. It's completely new so there is no legacy code, and it can be extended without change simply by defining more event class strings. No new data structures are defined.
If I knew how to submit a change request to the pertinent browser standards committee, this seems to me like a very tight, robust, compatible solution to several problems. I'm recording this here as a sort of message in a bottle, in the hope that one day it will be seen by someone who can act on it.
What's the difference among
.createServerHandler,
.createServerClickHandler,
.createClickHandler
?
Thanks
referring to the doc method createServerClickHandler(functionName) - deprecated 2012-03-06
in favor of createServerHandler which creates the 'generic' server handler in the Uiinstance. The createClickHandler is one of many methods that defines the behavior of the handler : click/change/mouse/key... (see doc of the element you use) and the possible options will be different depending of the type of element.
Note that the autocomplete feature allows to see easily what handlers are available for each Ui element.
Also important to remember, a server side handler sends your request to the server to perform the and then sends the request response back to your application, which can have some latency.
If you have a task like disabling a button immediately after it is pressed, you can use a client handler which performs the operation inside the browser and doesn't have the latency that a server handler would have.
More info:
Handlers in general
https://developers.google.com/apps-script/guide_user_interfaces#UIUpdate
Client handlers
https://developers.google.com/apps-script/guide_user_interfaces#ClientHandlers
Hope that helps,
Ryan
Thanks for your reply for my question: Is this a bug of Box API v2 when getting events
This is a new problem related to this. The problem is that I cannot reliably use the next_stream_position I got from previous calls to track events.
Given this scenario:
Given the following two GET HTTP queries:
1. GET https://api.box.com/2.0/events?stream_position=1336039062458
This one returns the JSON file which contains one file entry of myfile.pdf and the next stream position = 1336039062934
2. GET https://api.box.com/2.0/events?stream_position=1336039062934
This call uses the stream position I got from the first call. However, it returns the JSON contains the exactly same file entry of myfile.pdf with the first call.
I think if the first call gives a stream position, it should be used as a mark for that exact time (say: TIme A). If I use that stream position in subsequent queries, no events before "Time A" should be returned.
Is this a bug? Or did I use the API in the wrong way?
Many thanks.
Box’s /events endpoint is focused on delivering to you a highly reliable list of all the events relevant to your Box account. Events are registered against a time-sequenced list we call the stream_position. When you hit the /events API and pass in a stream_position we respond to you with the events that happened slightly before that stream position, up to the current stream_position, or the chunk_size, whichever is lesser. Due to timing lag and our preference to make sure you don’t miss some event, you may receive duplicate events when you call the /events API. You may also receive events that look like they are ‘before’ events that you’ve already received. Our philosophy is that it is better for you to know what has happened, than to be in the dark and miss something important.
Box events currently give you a window roughly 5 seconds into the past, so that you don't miss some event.
We have considered just delaying the events we send you by about 5 seconds and de-duplicating the events on our side, but at this point we've turned the dial more towards real-time. Let us know if you'd prefer a fully de-duped stream, that was slower.
For now, (in beta) if you write your client to check for duplicate events, and discard them, that will be best. We are about to add an event_id to the payload so you can de-duplicate on that. Until then, you'll have to look at a bunch of fields, depending on the event type... It's probably more challenging that it is worth.
In order to help you be able to figure out if an event is a duplicate, we have now added to each event an event_id that will be unique. It is our intention that the event_id will allow you to de-duplicate the responses you receive from subsequent GET /events calls.
You can see this reflected in the updated documentation here, including example payloads.