Bugzilla

Richard, these are interesting results and seem to indicate a increased batch size has time saving benefits assuming someone has a connection of 4G or, perhaps, 3Mb Internet service or better. I'm testing a calendar.caldav.multigetBatchSize = 1000 right now to see if it makes any difference or not. I don't know that I have that many cal events but I'll dive in to see if my GMail accounts complain here at work or at home.

Devs, may I ask when or during what TB era the default setting of 100 was established?

Also, is there a mechanism by which TB can query a server for batch size limit or perhaps some debugging on console method that might show a threshold limit having been hit if one, say, sets it to 100,000? 10,000,000? If 100 was set arbitrarily, is there some RFC spec that states the ceiling limit? I'd suspect Google has a pretty beefy back end whereas smaller ISP CalDAV calendaring setups might balk at some really high numbers. But how to get TB to yield some quantitative metrics to potentially establish a newer baseline for 2022/2023?

Richard, these are interesting results and seem to indicate a increased batch size has time saving benefits assuming someone has a connection of 4G or, perhaps, 3Mb Internet service or better. I'm testing a calendar.caldav.multigetBatchSize = 1000 right now to see if it makes any difference or not. I don't know that I have that many cal events but I'll dive in to see if my GMail accounts complain here at work or at home.

Devs, may I ask when or during what TB era the default setting of 100 was established?

Also, is there a mechanism by which TB can query a server for batch size limit or perhaps some debugging or console method that might show a threshold limit having been hit if one, say, sets it to 100,000? 10,000,000? If 100 was set arbitrarily, is there some RFC spec that states the ceiling limit? I'd suspect Google has a pretty beefy back end whereas smaller ISP CalDAV calendaring setups might balk at some really high numbers. But how to get TB to yield some quantitative metrics to potentially establish a newer baseline for 2022/2023?

Richard, these are interesting results and seem to indicate a increased batch size has time saving benefits assuming someone has a connection of 4G or, perhaps, 3Mb Internet service or better. I'm testing a calendar.caldav.multigetBatchSize = 1000 right now to see if it makes any difference or not. I don't know that I have that many cal events but I'll dive in to see if my GMail accounts complain here at work or at home.

Devs, may I ask when or during what TB era was the default setting of 100 established?

Also, is there a mechanism by which TB can query a server for batch size limit or perhaps some debugging or console method that might show a threshold limit having been hit if one, say, sets it to 100,000? 10,000,000? If 100 was set arbitrarily, is there some RFC spec that states the ceiling limit? I'd suspect Google has a pretty beefy back end whereas smaller ISP CalDAV calendaring setups might balk at some really high numbers. But how to get TB to yield some quantitative metrics to potentially establish a newer baseline for 2022/2023?