I’m looking to improve the efficiency of the calendar (in trunk) by
reducing requests, I’d like your opinion(s) on the strategy, to check
I’m on the right track.
The previous method was to completely redraw the entire app whenever
anything (view, search, date, category, calendar owner, status)
changed.
Now I have it only changing the events, while keeping as much of the
UI as we can so we don’t have to re-draw what hasn’t changed. I still
have to fetch the data whenever the filters (search, date, category,
owner, status) change, but now don’t have to redraw the entire view,
or the sidebox.
I’d like to take this a step further and start caching some of the
events [1] so that if you go from a month view to a week view, (or
week to day) no additional server request is needed. The data is
already there and displayed, we just need to know it’s still valid to
be used, and that it matches the current filters.
I’m thinking that as long as it’s just the date changing within a
range that is already known on the client, we can keep the list of
events we already have (indexed by date), but if any of the others
(search, category, owner, status) change we’ll have to get new data.
Does that sound like a valid strategy? Are there any pitfalls or
other improvements I’ve missed?
[1] The nextmatch & data API already cache the actual event data,
indexed by ID, so it could just be referenced.
Nathan
Don’t Limit Your Business. Reach for the Cloud.
GigeNET’s Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
