These are chat archives for exceptionless/Discuss

28th
Jan 2016
Eric J. Smith
@ejsmith
Jan 28 2016 00:17
@srijken how about sorting the keys and then doing the hashes in that order?
@srijken thought of a problem. User identity is going to cause them to be different
Eric J. Smith
@ejsmith
Jan 28 2016 00:22
And
Was hoping that we would really be able to save a lot of dupes from being sent, but it's really common to have a single error happen with all different users.
Blake Niemyjski
@niemyjski
Jan 28 2016 02:02
Not really on a desktop app
They will be the same user
Eric J. Smith
@ejsmith
Jan 28 2016 03:12
Yeah, it will still catch dupes for sure. Just not as many as I was originally thinking.
Sander Rijken
@srijken
Jan 28 2016 12:59
well we can choose not to include the user in the hashes ofcourse..
that would make things easier
I thought about sorting the hashtable keys, works fine for Dictionary<string, TSomething>, but not for Dictionary<TCustomTpe, TSomething>
Eric J. Smith
@ejsmith
Jan 28 2016 13:01
We need to include user identity. I want tone able to report things like how many users are affected by an error or what percent of user sessions have errors.
Sander Rijken
@srijken
Jan 28 2016 13:02
yeah, well in that case it won't catch as much dupes
Eric J. Smith
@ejsmith
Jan 28 2016 13:02
Where do we have non-string key dictionaries?
Sander Rijken
@srijken
Jan 28 2016 13:02
don't think you have those
so that could work yeah
it's also an easy enough fix, all dictionary compares/hashing is in a helper
Eric J. Smith
@ejsmith
Jan 28 2016 13:02
Yeah and it's up to each object to implement gethashcode
Sander Rijken
@srijken
Jan 28 2016 13:03
yeah
Eric J. Smith
@ejsmith
Jan 28 2016 13:03
So if some other object has something weird the. It can decide how to handle it.
Sander Rijken
@srijken
Jan 28 2016 13:03
yeah
Blake Niemyjski
@niemyjski
Jan 28 2016 14:11
@srijken is all that committed?
I could work on a test this afternoon (many hours from now)
a test with complex errors
I’m meeting up with the elastic search guys this morning
Sander Rijken
@srijken
Jan 28 2016 14:18
it's committed, but not yet the sorted keys @ejsmith was suggesting
Sander Rijken
@srijken
Jan 28 2016 14:37
the other thing that needs to be added is the counter that indicates how many dupes were found
Blake Niemyjski
@niemyjski
Jan 28 2016 14:52
ok
Blake Niemyjski
@niemyjski
Jan 28 2016 18:40
@ejsmith exceptionless/Exceptionless@a070ee4
Sander Rijken
@srijken
Jan 28 2016 18:57
@niemyjski I’ll change the dictionary stuff around
Sander Rijken
@srijken
Jan 28 2016 19:12
@ejsmith @niemyjski if any of you has a minute to think about the dupe count again let me know, not in a hurry or anything :)
Sander Rijken
@srijken
Jan 28 2016 19:25

what I’m preparing now.. whenever the dupechecker is being hit, the count is increased (saved inside the dupechecker plugin). When an event comes in after that that matches the hashcode, but the time is expired, attach the count to the event.

Last time we discussed what to do when the event to trigger this doesn’t come, not exactly sure how to handle that. I can also hang on to the event, so use the first event that hits the dupechecker (second event within 2 secs of the first one), to store the count, and send that along when the repeatwindow expires

Sander Rijken
@srijken
Jan 28 2016 19:32
I do have some doubts about keeping a reference to the event in the plugin though (perf, memory etc)
Eric J. Smith
@ejsmith
Jan 28 2016 19:51
Reading...
yeah, I think you would let the 1st pass through… then the 2nd you store in a dictionary<string, event>… with the key being the hash… then when you get another match you increment the value on the stored event.
as for sending...
Sander Rijken
@srijken
Jan 28 2016 19:54
right
I wasn’t sure it was OK to store the event
then again, we store max 10
Eric J. Smith
@ejsmith
Jan 28 2016 19:55
I think we could store something like EventInfo that stores the event, the DateTime and the ExceptionlessClient ref in the dictionary...
then you have a timer that runs periodically and sends them.
you have access to the client that the original was sent on… so you just do client.Send(event)
Sander Rijken
@srijken
Jan 28 2016 19:56
right
Eric J. Smith
@ejsmith
Jan 28 2016 19:56
think that would work?
Sander Rijken
@srijken
Jan 28 2016 19:56
probably
what’s a good place to stuff the counter, so you can pick it up at the server later on?
Eric J. Smith
@ejsmith
Jan 28 2016 19:57
on the value field of the event.
Sander Rijken
@srijken
Jan 28 2016 19:57
and how often does this timer need to run? If no dupes are detected it probably shouldn’t be running
value field isn’t used for other stuff?
Eric J. Smith
@ejsmith
Jan 28 2016 19:58
I’d say that we can bump this dupe window up since we are literally checking for the exact same event and we want to get these things to roll up.
but I’d say maybe 5-10 secs at most for sending the batches.
what are you thinking?
I guess maybe it could even be more than that.
Sander Rijken
@srijken
Jan 28 2016 20:00
right
Eric J. Smith
@ejsmith
Jan 28 2016 20:00
you know that you sent 1 of these exact same events already… so maybe you can hold on to the repeat ones even longer.
Sander Rijken
@srijken
Jan 28 2016 20:00
maybe also look at debounce logic
when it stops occurring all the time, that’s also a good moment to send
Eric J. Smith
@ejsmith
Jan 28 2016 20:01
yeah
agreed although it may never stop.
Sander Rijken
@srijken
Jan 28 2016 20:01
yeah
Eric J. Smith
@ejsmith
Jan 28 2016 20:01
so has to be some sort of cap on it.
Sander Rijken
@srijken
Jan 28 2016 20:01
indeed
either time based, or value based
Eric J. Smith
@ejsmith
Jan 28 2016 20:01
but I guess since we let 1 through already… I am good with being aggressive on rolling up subsequent occurrences.
Sander Rijken
@srijken
Jan 28 2016 20:02
or maybe both
Eric J. Smith
@ejsmith
Jan 28 2016 20:04
are you working on this in a branch?
Sander Rijken
@srijken
Jan 28 2016 20:06
Yeah
Eric J. Smith
@ejsmith
Jan 28 2016 20:07
if you send me a link I can take a look tonight and give you any feedback I might have.
Sander Rijken
@srijken
Jan 28 2016 20:07
just deduplication
Eric J. Smith
@ejsmith
Jan 28 2016 20:07
this is going to be a really useful feature! really appreciate your help
Sander Rijken
@srijken
Jan 28 2016 20:08
The branch name. Didnt mean to hit enter yet ;)
Eric J. Smith
@ejsmith
Jan 28 2016 20:08
ahh got it.
nice
Sander Rijken
@srijken
Jan 28 2016 20:08
im really looking forward to this too. We have a few places that tend to escalate out of control
Eric J. Smith
@ejsmith
Jan 28 2016 20:09
I will create a pull request for it so we can have a conversation in there.
Sander Rijken
@srijken
Jan 28 2016 20:09
yeah good then it's documented :)
Don't pull yet though :)
Eric J. Smith
@ejsmith
Jan 28 2016 20:10
yeah :-)
Sander Rijken
@srijken
Jan 28 2016 20:12
I just pushed to sorted key dictionary compares. Now the detection works so it's time to make it do something
Eric J. Smith
@ejsmith
Jan 28 2016 20:12
looking good
Sander Rijken
@srijken
Jan 28 2016 20:12
whats the current thing value is used for?
Eric J. Smith
@ejsmith
Jan 28 2016 20:12
I like it.
value is used for whatever you want to use it for.
Sander Rijken
@srijken
Jan 28 2016 20:13
right but there's not a chance it's already being used for something else?
Blake Niemyjski
@niemyjski
Jan 28 2016 20:13
could
but probably won’t be for errors
Sander Rijken
@srijken
Jan 28 2016 20:13
oh and it needs to be removed from the hash code calculation ;)
Blake Niemyjski
@niemyjski
Jan 28 2016 20:14
well
it would only be set when the dedup passes along the event with the updated count
so I think you can include it
Sander Rijken
@srijken
Jan 28 2016 20:15
But will you be able to known on the server that it was a value that was used for deduplication?
ugh autocorrect :(
Blake Niemyjski
@niemyjski
Jan 28 2016 20:15
well be scoped to type:error and we’ll just have to use it?
not sure
that’s erics baby lol
Blake Niemyjski
@niemyjski
Jan 28 2016 20:26
guess we’ll have to figure that out
Blake Niemyjski
@niemyjski
Jan 28 2016 20:32
@srijken do we have an open issue for deduping?
getting people asking about it
Eric J. Smith
@ejsmith
Jan 28 2016 20:33
so we should include value if it is populated and not equal to 1.
I don’t want this scoped to errors only… I want it to dedupe other things like feature usages
the idea here is that we are going to provide charts that use value and that will be generally useful for a bunch of things including this.
it’s getting really good
dang string literal types
that’s cool
Eric J. Smith
@ejsmith
Jan 28 2016 20:58
that looks nice
Eric J. Smith
@ejsmith
Jan 28 2016 20:58
other than bringing JSX support in.
Blake Niemyjski
@niemyjski
Jan 28 2016 20:58
yeah
I don’t like that
class FileSystemObject {
isFile(): this is File { return this instanceof File; }
isDirectory(): this is Directory { return this instanceof Directory;}
isNetworked(): this is (Networked & this) { return this.networked; }
constructor(public path: string, private networked: boolean) {}
}
what is that stuff
between isFile() and {
Blake Niemyjski
@niemyjski
Jan 28 2016 21:05
@frankebersoll did they get rid of bundling support.. I don’t see it anywhere on there timeline
Sander Rijken
@srijken
Jan 28 2016 22:11
when sending the event along, I need PluginContextData.. cache that as well?
Blake Niemyjski
@niemyjski
Jan 28 2016 22:30
yeah probably
I’m not sure about all of this to be honest
Sander Rijken
@srijken
Jan 28 2016 22:30
what’s the lifetime of a plugin?
Blake Niemyjski
@niemyjski
Jan 28 2016 22:30
I know we talked about this, it just doesn’t sit right with me that a plugin pipeline would keep onto events and then delay send them
or is it just going to wait for the next one to pass through and attach the value and let it through? what if no more events come through then we just discarded x
guess we are fine with that right??
Sander Rijken
@srijken
Jan 28 2016 22:31
we can solve that second problem with a timer
Blake Niemyjski
@niemyjski
Jan 28 2016 22:31
well that’s just it.
Sander Rijken
@srijken
Jan 28 2016 22:31
that way it’ll always get sent
Blake Niemyjski
@niemyjski
Jan 28 2016 22:31
I thought a plugin was always just to process an event and be done
but this plugin is sitting in with a bunch of plugins.. how are we sure it’s been processed by them all?
and then there are callbacks etc.
Eric J. Smith
@ejsmith
Jan 28 2016 22:32
@niemyjski what exactly is wrong with a plugin sending events on it’s own?
Blake Niemyjski
@niemyjski
Jan 28 2016 22:32
personally, (not sure what ejsmith thinks about this). but I’d be happy if we were just discarding them and keeping track of how many and then when the next one comes though we attach that count to it
because the plugin is meant for processing prior to enqueueing and knows nothing about sending / submisssion
Eric J. Smith
@ejsmith
Jan 28 2016 22:33
if you do that then you have zero guarantee that it will get though
Sander Rijken
@srijken
Jan 28 2016 22:33
but, using your own argument here, what if that next event doesn’t come?
Eric J. Smith
@ejsmith
Jan 28 2016 22:33
because it doesn’t have the event to send
Blake Niemyjski
@niemyjski
Jan 28 2016 22:33
well then you deduplicated those events
Eric J. Smith
@ejsmith
Jan 28 2016 22:33
we can make sure that the queued up events will get sent
Blake Niemyjski
@niemyjski
Jan 28 2016 22:34
just seems odd
Eric J. Smith
@ejsmith
Jan 28 2016 22:34
why?
Sander Rijken
@srijken
Jan 28 2016 22:35
just one intermediate question.. how long is a plugin alive? and is there IDisposable support?
Blake Niemyjski
@niemyjski
Jan 28 2016 22:35
because the whole process should be repeatable / stateless and now were highjacking events maybe mid plugin pipeline and then sending them possibly in an incomplete state
yes, there is disposable support
Sander Rijken
@srijken
Jan 28 2016 22:35
ok
Blake Niemyjski
@niemyjski
Jan 28 2016 22:35
and a plugin is created once and reused
once per client instance
Eric J. Smith
@ejsmith
Jan 28 2016 22:35
we are buffering events… the same exact way we are buffering them in the queue.
how is this different?
the only difference is that we are buffering and de-duplicating them.
and that is extremely valuable.
Blake Niemyjski
@niemyjski
Jan 28 2016 22:36
so.. are we are storing a reference to the event and letting the rest of the plugins run? then what checking a flag somewhere so it’s not enqueued?
yeah I get that
Eric J. Smith
@ejsmith
Jan 28 2016 22:36
so what is the problem then?
Blake Niemyjski
@niemyjski
Jan 28 2016 22:36
just wonder if the place for this is in a plugin
Eric J. Smith
@ejsmith
Jan 28 2016 22:36
it’s exactly the place.
Sander Rijken
@srijken
Jan 28 2016 22:36
we’re not letting the rest of the plugins run
just the plugins in front of this one
Blake Niemyjski
@niemyjski
Jan 28 2016 22:37
ok
Eric J. Smith
@ejsmith
Jan 28 2016 22:37
and if our plugins are not poweful enough to handle it then we should make the plugin system more powerful.
Blake Niemyjski
@niemyjski
Jan 28 2016 22:37
so the first event goes through, what happens to the next exact event (can you walk me through this)
Eric J. Smith
@ejsmith
Jan 28 2016 22:37
the entire idea of the plugin system is to be able to alter the way the client works.
Sander Rijken
@srijken
Jan 28 2016 22:37
the next event is thrown away
Blake Niemyjski
@niemyjski
Jan 28 2016 22:38
ok
Sander Rijken
@srijken
Jan 28 2016 22:38
we just count it, we can throw it away because it’s exactly the same as the first one
Blake Niemyjski
@niemyjski
Jan 28 2016 22:38
so basically
Sander Rijken
@srijken
Jan 28 2016 22:38
(except for timestamp ofcourse)
Blake Niemyjski
@niemyjski
Jan 28 2016 22:38
we are storing the first event reference, updating the counter, and last submission (duplicate time) and resending it
Sander Rijken
@srijken
Jan 28 2016 22:38
something like that
Blake Niemyjski
@niemyjski
Jan 28 2016 22:38
first event (as reference)
ok
I was confused and it sounded like the second one was being buffered
and I was like what??
lol
Sander Rijken
@srijken
Jan 28 2016 22:39
no it’s not :)
Blake Niemyjski
@niemyjski
Jan 28 2016 22:39
my bad...
on your page now :)
Sander Rijken
@srijken
Jan 28 2016 22:39
depends on when you start counting too, that’s also confusing.. the first event gets through, the second event is the one being buffered, because you need 2 to have a dupe
the thing I’m having a hard time with with the timer stuff is the fact that they’re stored in a queue
Blake Niemyjski
@niemyjski
Jan 28 2016 22:40
I’d count any that you discard minus 1
Sander Rijken
@srijken
Jan 28 2016 22:40
oh wait I know, nevermind
Blake Niemyjski
@niemyjski
Jan 28 2016 22:40
:)
Sander Rijken
@srijken
Jan 28 2016 22:40
just need to send anything with count > 1 when the timer hits
sending it should reset the timer
Blake Niemyjski
@niemyjski
Jan 28 2016 22:41
I think you’d send anything in there that has exceeded the dedup time
Sander Rijken
@srijken
Jan 28 2016 22:41
there’s potential for a race condition there where it gets sent twice
(once because an event comes in that exceeds the cap, timer can go off at the same moment)
Blake Niemyjski
@niemyjski
Jan 28 2016 22:48
guess well have to test it a bunch
Sander Rijken
@srijken
Jan 28 2016 22:48
yeah
won’t be easy
especially because much of it is time based
and you don’t want a testcase lasting forever
Blake Niemyjski
@niemyjski
Jan 28 2016 22:52
yeah
we can set a property on the plugin that has the timer interval
and then we can test just that plugin
Sander Rijken
@srijken
Jan 28 2016 22:54
we can do 2 things: a) just have a timer that checks events with firstoccurence < somevalue, and send those off. I like this because it’s simple, just one timestamp to check. b) have a firstoccurrence and lastocurrence. do the same as in a, but also when lastoccurence < someothervalue send it away too
b is more like debounce, but also make the whole thing more complex.. I think we should start keeping it simple
Sander Rijken
@srijken
Jan 28 2016 23:00
exceptionless/Exceptionless.Net@5c9f332
I’m open for all kinds of tweaks with the windows/timer intervals etc
Blake Niemyjski
@niemyjski
Jan 28 2016 23:04
I’d take a look at the heartbeat plugin
any specific reason for creating all those properties in the model? they should all be on the context
well they are on the context is what I’m trying to say and it only looks like your using client
I dispose the timer and set it to null
on your callback, I’d just access recently processed errors
it’s a concurrent queue
should be thread safe
Sander Rijken
@srijken
Jan 28 2016 23:06
instead of ToList()?
Blake Niemyjski
@niemyjski
Jan 28 2016 23:07
look at the first line your getting the queue when you already have it
Sander Rijken
@srijken
Jan 28 2016 23:07
thing is, I’m resetting the times when calling Send(), not sure if that hurts the Where clause
Blake Niemyjski
@niemyjski
Jan 28 2016 23:07
_recentlyprocessederrors
Sander Rijken
@srijken
Jan 28 2016 23:07
no
callback is static
Blake Niemyjski
@niemyjski
Jan 28 2016 23:07
shouldn’t have to be static
I don’t think my heartbeat one is
Sander Rijken
@srijken
Jan 28 2016 23:08
right
that makes things easier
Blake Niemyjski
@niemyjski
Jan 28 2016 23:09
yeah
also..
the send won’t work
it will sent the event through the whole pipeline again
it needs to be enqueued into the queue
Sander Rijken
@srijken
Jan 28 2016 23:10
how can I fix that?
Blake Niemyjski
@niemyjski
Jan 28 2016 23:10
get the queue from the resolver
Sander Rijken
@srijken
Jan 28 2016 23:10
it should pass through the plugins following the dedupplication plugin
Blake Niemyjski
@niemyjski
Jan 28 2016 23:10
and enqueue it
it won’t be able to
that’s why your storying the original reference which has went through everything
which is why it’s kind of goofy
Sander Rijken
@srijken
Jan 28 2016 23:11
when context.Cancel is set to true, it still passes through the remaining plugins?
Blake Niemyjski
@niemyjski
Jan 28 2016 23:12
nope
immediately bails
Sander Rijken
@srijken
Jan 28 2016 23:12
hmf, then a lot of information will be missing
Blake Niemyjski
@niemyjski
Jan 28 2016 23:13
I was pointing to that earlier
but then you said you are keeping the first submitted event
and duping the rest
the first event will be successful and will have went through everything. it will be updated in your cache because it’s pointing to a reference
:)
Sander Rijken
@srijken
Jan 28 2016 23:13
now I understand why you got confused :)
right
Blake Niemyjski
@niemyjski
Jan 28 2016 23:14
which the next consern is if we are only keeping the last 10 events...
Sander Rijken
@srijken
Jan 28 2016 23:14
I think I just went through the same thought process you did a while ago
Blake Niemyjski
@niemyjski
Jan 28 2016 23:14
what happens if i send 10 random log messages and now send errors
nothing was deduped
Sander Rijken
@srijken
Jan 28 2016 23:14
yeah.. that’s a thing.
that’s not the main concern
Blake Niemyjski
@niemyjski
Jan 28 2016 23:15
no?
Sander Rijken
@srijken
Jan 28 2016 23:15
it should check if the things that are dequeued should be sent
Blake Niemyjski
@niemyjski
Jan 28 2016 23:15
I’m worried about memory + memory leaks
this code needs to be dead simple cause I have to translate this to javascript
and that sucks lol
Eric J. Smith
@ejsmith
Jan 28 2016 23:16
Yeah, that is why I was thinking that we keep 2 separate lists… 1 is similar to what we have now with just the event hashes and timestamps… then we only store and delay the 2nd one...
Blake Niemyjski
@niemyjski
Jan 28 2016 23:16
well that’s logic in the timer to see if it should be sent
Eric J. Smith
@ejsmith
Jan 28 2016 23:16
that way we aren’t filling up the queue with a crapload of events that never get duped.
Sander Rijken
@srijken
Jan 28 2016 23:17
if you’re sending 10 random log messages, and then a lot of errors.. what will happen is that the first error will push the first log entry out of the queue
right I gotcha
Eric J. Smith
@ejsmith
Jan 28 2016 23:17
so 1st list is hash => timestamp… we check that to see if the current event is a dupe… if so we store the event and delay it...
Blake Niemyjski
@niemyjski
Jan 28 2016 23:17
@ejsmith what about when you are delaying an event in your use case… because you want to give it a bit to see if dups.. but then bam.. the app dies?
or unhandled error
kinda stinks
Eric J. Smith
@ejsmith
Jan 28 2016 23:18
same as if we have items in the queue now.
if the app shuts down normally, we flush the queue.
Sander Rijken
@srijken
Jan 28 2016 23:18
that won’t happen :P
oh that queue
Blake Niemyjski
@niemyjski
Jan 28 2016 23:18
guess what I meant to say
is your delaying this in a buffer
and it’s not enqueued
and so process queue on process exit won’t have nothing to process.
Eric J. Smith
@ejsmith
Jan 28 2016 23:18
we don’t have to capture every damn event… especially not these ones… because we already let the original one go through.
if we lose some dupes then I am not that upset.
Blake Niemyjski
@niemyjski
Jan 28 2016 23:19
what if we just wired up to the submitted event
and handled everything there
then we knew the plugin pipeline handled everything
and if the user didn’t want to cancel out of it
and that would be the perfect place to buffer it
or discard it
Eric J. Smith
@ejsmith
Jan 28 2016 23:20
huh?
Blake Niemyjski
@niemyjski
Jan 28 2016 23:20
right now things run through a pipeline then hit a user event to see if they want to cancel submission
Eric J. Smith
@ejsmith
Jan 28 2016 23:21
this should be done as a plugin and people can remove it if they want to.
Blake Niemyjski
@niemyjski
Jan 28 2016 23:21
be easiest to just hook this into after all that happens
so any non canceled events would hit this
after the submitted event
Eric J. Smith
@ejsmith
Jan 28 2016 23:21
dude again, this is what plugins are for… if this doesn’t work good in the plugins system then we should make the plugins system better.
but I don’t see any issues with the current approach.
Blake Niemyjski
@niemyjski
Jan 28 2016 23:22
kinda hard when the plugins are like a linked list and we high jack it right in the middle.. seems like we all got confused on how it works even after we’ve discussed it
can we agree on that at least?
ok, guess we keep down this approach and we see how it works...
Eric J. Smith
@ejsmith
Jan 28 2016 23:23
agree on what?
Blake Niemyjski
@niemyjski
Jan 28 2016 23:23
now I understand why you got confused :)
@srijken said that
Sander Rijken
@srijken
Jan 28 2016 23:23
huh? :)
Blake Niemyjski
@niemyjski
Jan 28 2016 23:23
or if plugins had two stages
saying why we both got confused on this
at roughly the same spot
Sander Rijken
@srijken
Jan 28 2016 23:24
oh that
Eric J. Smith
@ejsmith
Jan 28 2016 23:24
sorry I have to keep coming in and out of this conversation… I am here for a while now…
what is the confusion?
Sander Rijken
@srijken
Jan 28 2016 23:25
uhm
Blake Niemyjski
@niemyjski
Jan 28 2016 23:26
I’m leaving for dinner, it’s best to reread the past 3 pages of gitter
kinda walks through our though process
thought*
Sander Rijken
@srijken
Jan 28 2016 23:26
when you detected a dupe (2nd event), you can’t cancel that one.. you have to store that one, let that run through the whole pipeline. Starting from the third you can start discarding them. The journey to get trough that conclusion is what caused it I think
Blake Niemyjski
@niemyjski
Jan 28 2016 23:27
yup
Eric J. Smith
@ejsmith
Jan 28 2016 23:27
ok… going through this...
Sander Rijken
@srijken
Jan 28 2016 23:27
so right now we can start discarding the second event, because I’m now storing all the data for the last 10 events, which isn’t a good idea
Eric J. Smith
@ejsmith
Jan 28 2016 23:27
1st goes through… stores a hash and a timestamp in a dictionary… nothing more.
Blake Niemyjski
@niemyjski
Jan 28 2016 23:27
which maybe the plugins should have a run method and a ran method (names could be better)
Eric J. Smith
@ejsmith
Jan 28 2016 23:27
2nd comes through, matches the hash in the dictionary which means we have a dupe inside of the time window...
Blake Niemyjski
@niemyjski
Jan 28 2016 23:28
@srijken I don’t think he’s following us
Eric J. Smith
@ejsmith
Jan 28 2016 23:28
2nd event can be cancelled and stored in a queue
Blake Niemyjski
@niemyjski
Jan 28 2016 23:28
no it can't
Sander Rijken
@srijken
Jan 28 2016 23:28
no it can't
Eric J. Smith
@ejsmith
Jan 28 2016 23:28
why not?
Blake Niemyjski
@niemyjski
Jan 28 2016 23:28
because it hasn’t ran through all the plugins
Sander Rijken
@srijken
Jan 28 2016 23:28
because the other plugins still have to process it
lol
Blake Niemyjski
@niemyjski
Jan 28 2016 23:28
lol
Eric J. Smith
@ejsmith
Jan 28 2016 23:28
ok, so make sure it’s inserted at the end.
Blake Niemyjski
@niemyjski
Jan 28 2016 23:28
I’ll let you talk. I’m going to dinner
Eric J. Smith
@ejsmith
Jan 28 2016 23:28
give it a high priority
Sander Rijken
@srijken
Jan 28 2016 23:28
that would work too
Eric J. Smith
@ejsmith
Jan 28 2016 23:29
if people run things after then that is their problem
this is literally what the plugin system is designed for… for people and us to be able to modify the behaviour of the client.
am I missing something?
Sander Rijken
@srijken
Jan 28 2016 23:30
don’t think there’s a problem if this is the last (or almost last) plugin to run
that makes sense too.. first you have a bunch of plugins adding data, after they’re done adding data you start filtering
I should be going btw.. to be continued some other time :)
Eric J. Smith
@ejsmith
Jan 28 2016 23:32
this is logic just like any other logic in the app where order matters… if someone want to inject something after this then they made that decision… but the point is that the plugins are pluggable logic that people can add to or remove.
Sander Rijken
@srijken
Jan 28 2016 23:32
yeah I agree
Eric J. Smith
@ejsmith
Jan 28 2016 23:32
ok, thank you for working on this and dealing with all the confusion. :-)
Sander Rijken
@srijken
Jan 28 2016 23:32
I think I learned a lot in the end :)
Eric J. Smith
@ejsmith
Jan 28 2016 23:32
awesome! That is all that matters. :-)
Sander Rijken
@srijken
Jan 28 2016 23:33
showing the code also helps to get the discussion going, which is good
Eric J. Smith
@ejsmith
Jan 28 2016 23:33
yeah, love github for that!
Sander Rijken
@srijken
Jan 28 2016 23:33
makes sure we’re all talking about the same thing
Eric J. Smith
@ejsmith
Jan 28 2016 23:33
yep
pretty fun collaborating with other people on a project.
Sander Rijken
@srijken
Jan 28 2016 23:34
tomorrow I’ll try to make sure we don’t cache any data we don’t need to, move the priority
Eric J. Smith
@ejsmith
Jan 28 2016 23:34
especially people from all over the world.
Sander Rijken
@srijken
Jan 28 2016 23:34
yeah :)
Eric J. Smith
@ejsmith
Jan 28 2016 23:34
maybe someday we can do a meet up!
Sander Rijken
@srijken
Jan 28 2016 23:34
who knows :)
ttyl
Eric J. Smith
@ejsmith
Jan 28 2016 23:35
later man
have a good night