is it better to create new DAVClients or reuse one DAVClient for long-term repeated syncing tasks?

[throni3git]

hi,
thanks for this package. i am working on a calendar syncing app using the DAVClient. as i did not find an example on that topic, how is it supposed to be used for long-term usage with repeated syncing tasks? either closing and creating a new DAVClient for every syncing run or should it be only one DAVClient being used all the time?

e.g. pseudo code

cal_primary = "..."

while True:
    client = caldav.DAVClient(cal_primary, username="...", password="...")
    principal = client.principal()
    calendars = self.principal.calendars()
    # do something with the calendars
    client.close()
   time.sleep(60)

or

cal_primary = "..."
client = caldav.DAVClient(cal_primary, username="...", password="...")
principal = client.principal()

while True:
    calendars = self.principal.calendars()
    # do something with the calendars
   time.sleep(60)

in my use case i use the APScheduler package [1]

[1] https://github.com/agronholm/apscheduler

[tobixen]

thanks for this package. i am working on a calendar syncing app using the DAVClient. as i did not find an example on that topic,

DId you check the examples/sync_examples.py file?

either closing and creating a new DAVClient for every syncing run or should it be only one DAVClient being used all the time?

Thinking deeply about this, the answer is somwhere between "that depends" and "I don't know" :-)

Here are some hints:

• The DAVClient init process does not involve any server communication, the initialization of a DAVClient object should be considered to be "free".
• There is not much overhead in the DAVClient object, it basically only saves username, password, URL, etc.
• The DAVClient-object is stored in the calendar objects, calendar event objects, etc, so if you are to do operations on those and store those objects between each iteration, then it's definitively a bad idea to create one object for each loop iteration.
• The authentication mechanism works by first doing an initial request without username/password, probing what authentication mechanism the server wants, and then sending requests with authentication information. Meaning that there will be at least one extra http-request when a fresh DAVObject is used.
• When using HTTP/1.1 there is the "keepalive" feature, where multiple requests can share one TCP-connection. Creating TCP-connections on high-latency networks is expensive, so this is a great win when firing off many requests in a row. Of course, to utilize this it's needed to have one DAVClient object.
• When using HTTP/2 (only if your'e using niquests instead of requests - that depends on what version you're using), then in 2.x multiplexing will be enabled as default.
• I've never thought about it, but with "keepalive" and HTTP/2 it's probably a good idea to close the TCP-connection between the iterations. That may be done by using a context manager. With the context manager pattern, the intention would be that with newly created object: do some operations, meaning a new object should be created for every loop iteration.

`client = caldav.DAVClient(cal_primary, username="...", password="...")`

This is not according to the "best current practices" in 2.x. For one thing, use a context manager:

with DAVClient(...) as client:
    principal = client.principal()
    (...)

I must admit I've never thought of it before, but with keepalive and http/2 this will likely cause the TCP-connection to be closed when you're done with the session. With this pattern it's probably best to construct the DAVClient inside the while-loop.

Going forward it's recommended to use the factory method rather than the class constructor:

from caldav.davclient import get_davclient
with get_davclient() as client:
  principal = client.principal()
  (...)

Also, it's definitively not a good practice to have passwords and usernames hard-coded in the python file. get_davclient supports both fetching such information from the environment as well as from a config file.

[tobixen]

I asked the AI to do QA on my answer above. It agrees.

[throni3git]

thanks for the quick and extensive answer. you are right in terms of the best practices. parts of that are due to coming from a version 1.6 and not adapting to the get_davclient function. i will take a look on how to modernize the code to better match the best practices of 2.x :) (the credentials are not hardcoded as in the pseudo code, but thanks for taking care)

to clarify a bit more: the application will use the DAVClient every 15 minutes (instead of 60 seconds as i put in the pseudo code in my original post) and the # do something with the calendars part is then using the same DAVClient in both of my pseudo code variants. the purpose is to copy events from one or more calendars towards a target calendar, which was what i meant with "syncing".