Skip to content

Conversation

@prasad83
Copy link
Contributor

Delegating multi-get requests to Backend (GetCalendarObjects and GetAddressObjects)
Backend implementation can optimize the way it fetches details based on paths.

Added GetCalendarObjects function to interface.
Using it during handleMultiGet.
Added GetAddressObjects function to interface.
Using it during handleMultiGet.
caldav/server.go Outdated
@@ -36,6 +36,8 @@ type Backend interface {
GetCalendar(ctx context.Context, path string) (*Calendar, error)

GetCalendarObject(ctx context.Context, path string, req *CalendarCompRequest) (*CalendarObject, error)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we remove GetCalendarObject, to avoid having two functions which do a very similar thing? GetCalendarObject is equivalent to GetCalendarObjects with a single path.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both Single and Multiple Objects creation are required:

caldav Server options makes call to GetCalendarObject (which is single-get), GetCalendarObjects could either call GetCalendarObject or handle the bulk processing at Backend in it way.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The GET handler can invoke GetCalendarObjects with a single path in the list.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR updated: Replaced GetAddressObject & GetCalendarObject with GetAddressObjects & GetCalendarObjects and its demand in Backend interface too.

}

// multi-fetch and lookup collection
lookups := make(map[string]*CalendarObject)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need to build a lookup map? Can't we just iterate over the results?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is minor optimization (considering the objects could be more than 1000)

Copy link
Owner

@emersion emersion Oct 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm suggesting to replace the multiget.Hrefs loop below when building responses with a loop over objects.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@emersion - The lookups ensures we can match each href to its object efficiently and preserve request order without nested loops. It also gracefully handles missing paths.

This way, backend GetCalendarObjects or GetAddressObjects need to worry about the order of returned objects or missing those that are not found.

caldav/server.go Outdated
var err error
var found bool
if co, found = lookups[href.Path]; !found {
err = fmt.Errorf("Couldn't find calendar object at: %s", href.Path)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will not send a 404. We should use internal.HTTPErrorf() with http.StatusNotFound.

Copy link
Contributor Author

@prasad83 prasad83 Oct 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here error is packed into the responses return value.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The error doesn't have the HTTPError type, so will be encoded as a 500.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@emersion - Updated error handling as suggested.

@prasad83
Copy link
Contributor Author

@emersion - If there are more changes to review let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants