This project is read-only.


Jun 6, 2013 at 6:02 AM
Looks like you added event caching back into the EventData class. This makes it impossible to use this object model to write one of the most popular types of GW2 apps - dragon timers. These apps constantly query the events api to check for status changes. If we cache the events, those apps can't see event status changes.

We can cache the event names, but not the events themselves.

As a result, I've removed the event cache from this class again. I've also added some new indexers and changed the way events are retrieved so the caller has more control over what they retrieve, since everything you do here results in an API call.
Jun 6, 2013 at 11:22 AM
Edited Jun 6, 2013 at 12:19 PM
My intention was to start building an event system around the events.

I thought of this:

We have a cache that caches the events, completely. Then we have a boolean property where the user can specify if he wants to use the cache or not. The events will tell the user that some events have changed and returns a collection of the changed events.

However if we include that event system I'll do it in the main branch.
Jun 6, 2013 at 3:00 PM
As long as the caching can be turned off, that should be fine then. I'm just thinking of how I would use this for the dragon timers. The way I have it set up is that for each event I'm interested in I have:
 ActivationDelay: The amount of time after the event completes that the event will be unavailable
 LastCompletedTime: The last time the event was completed (changed from Active to either Success or Failed)
The API doesn't track any of this information, so I have to store this myself. When a dragon is on its ActivationDelay, I don't bother querying for updates to its status, because I know it won't change. Since I'm only interested in the 3 dragons for 1 server, my code can potentially go hours without calling the Events API for updates, since it's just not needed.

Once the activation window for a dragon begins, my code starts hitting the API every 10 seconds for updates, and continues doing that until it goes back into ActivationDelay.

So if the GW2.NET object model was caching all events and watching for changes on my behalf, it would be incredibly wasteful. It would have to retrieve all events every 10 seconds all the time, because it has no concept of ActivationDelay and it doesn't know when the event last completed.

Maybe one day they'll give us this information via the API, and we can stop having to write our own code for this. But until then, I'm not convinced an event caching mechanism is feasible within GW2.NET, unless we're going to code the activation information for every event and track the last completed time in a database, and let the caller specify which events they are interested in... which would be a huge and complex undertaking.
Jun 11, 2013 at 6:48 PM
Ok, I re-enabled caching but added a property to the EventData provider to disable caching. If the property is set to true then the data provider will always query the api and not use the cache (it will however not null the cache but also not update it. I'm working on an update in the background when the user querys the api).