Optimize AJAX requests on timetable: add session, add contribution

[jbenito]

The request to get favourites (and others) is to slow.
Also, this is related to task #283

[dmartinc]

Clarifying Jose's words:

-The add contribution and add session dialogs take quite a bit of time to open. Part of the blame lies in that up to 5 ajax requests are made before the dialog can open.
-Open of these requests is to get the user favourites. These could be loaded on page load and be passed as an argument to the dialog, instead of being requested by ajax.
-Also there is a duplicated ajax request (task #283) that happens in a lot of other places.
-Finally, maybe some of the other Ajax requests done on dialog opening could also be avoided, research this :)

[jbenito]

On top of AJAX requests improvements, check if we can speed up the process of opening the windows to add entries. Here some feedback from users:

Peux-tu me dire pourquoi quand je cree un agenda pour un meeting quand je suis dans la saisie TIMETABLE quand je clic sur ADD NEW soit session 
            soit Contribution 
            soit Break 
Et que la fenetre s'ouvre cela prend un temps infini avant que je puisse inserer un titre....
On voit que ca charge a chaque fois la salle....
C'est long.
Merci pour ton aide.
Carnita 

[pferreir]

On reducing the number of requests, there is a trade-off between sending as few requests as possible and making the service code manageable (i.e. having service.that.retrieves.x and service.that.retrieves.y, and a service.that.returns.xandy ).
Fortunately, json-rpc 2.0 established a mechanism for batch request support:

​http://groups.google.com/group/json-rpc/web/json-rpc-2-0 (point 5)

Implementing it should't be that hard, and would spare us a lot of work.
This would imply checking for a list of requests on the server side, and executing them all in the same call. As well, on the client side we should have a function that allows us to execute a "batch" of (service, args) pairs and process the results.

[ian.rolewicz@…]

commit a217dc1f7cb34e7f692e6e077fdcb0e32c875a17
Author: Ian Rolewicz <ian.rolewicz@…>
Date: Fri Mar 26 16:37:59 2010 +0100

[OPT] Optimization of the timetable display

• fixes #307
• Replaced pickling by fossilization for the generation of the data structures needed for the display of the timetable. The fossils contain the minimal amount of information needed to display the timetable, which is less than what the pickling was retrieving
• New minimal fossils were added for the managment timetable too.
• Optimized the loop that is grouping entries by day
• Removed dead code used for the management timetable generation
• Added a argument to the Fossils.fossilize(), ScheduleToJson?.process() and ScheduleToJson?.processEntry() method in order to use the attributes cache, useful for fossils that have fields that are repeated.
• Displaying the 'view event' timetable of a conference like 'CHEP 2009' takes now less than 8 seconds
• Displaying the 'managment' timetable of a conference like 'CHEP 2009' takes now less than 4 seconds

[Ian Rolewicz <ian.rolewicz@…>]

In [a217dc1f7cb34e7f692e6e077fdcb0e32c875a17]:

[OPT] Optimization of the timetable display

• fixes #307
• Replaced pickling by fossilization for the generation of the data structures needed for the display of the timetable. The fossils contain the minimal amount of information needed to display the timetable, which is less than what the pickling was retrieving
• New minimal fossils were added for the managment timetable too.
• Optimized the loop that is grouping entries by day
• Removed dead code used for the management timetable generation
• Added a argument to the Fossils.fossilize(), ScheduleToJson?.process() and ScheduleToJson?.processEntry() method in order to use the attributes cache, useful for fossils that have fields that are repeated.
• Displaying the 'view event' timetable of a conference like 'CHEP 2009' takes now less than 8 seconds
• Displaying the 'managment' timetable of a conference like 'CHEP 2009' takes now less than 4 seconds