New dav-server Moqui component

Technical Questions
1

I am starting a new topic for discussions related to the CalDav and CardDav implementation in Moqui. The repo can be found here: GitHub - grozadanut/dav-server: Moqui component that adds WebDAV support, mainly for CalDav and CardDav.

I have some implementation related questions that I need help with. First, to add some context, CalDav and WebDav in general is an extension to HTTP, so in order to implement it we have some requirements that we need to satisfy, specifically:

  1. Support for non standard HTTP methods: PROPPATCH, PROPFIND, ACL, REPORT…
  2. Read HTTP request headers(eg: Depth) and write response headers(eg: DAV)
  3. Return an XML body response.

Initially I was considering to use the REST services functionality in Moqui(rest.xml definitions), but I have some problems in satisfying the requirements above:

  1. I think this can be done by extending <xs:element name="method"> in rest-api-3.xsd file with the new methods.
  2. For reading headers I think you can get them from the execution context WebFacade, but for returning specific headers, this is not supported as I can see in RestApi line 250: return new RestResult(result, null) the result is created with null headers.
  3. As far as I understand the code I think only JSON response is supported. Not sure how to add XML support here.

There is also another requirement in the WebDAV ACL specification which states that for failed authentication we need to return not only an error status code, but also return a specific XML inside the response body that explains the error. Authentication is also handled by the Moqui framework, so not sure how to return a specific body on failed authentication.

So my question is: would it be feasible to extend the Moqui framework REST functionality, or is there another way in Moqui to create easy routings between a URL(with url placeholders like /calendar/{id} and method type like GET, PUT, REPORT, ACL...) and a service in which you can return XML and custom headers?

1 Like
2

Another problem I see with the current WorkEffort entity is the lack of grouping of calendar events based on calendars. For example, the user Danut might have 3 calendars: Personal, Work and Public, and when I select the Personal calendar only events from the Personal calendar should be shown. I see 3 approaches to achieve this functionality, not sure which one to choose yet:

  1. Extend WorkEffort entity with another field calendarId pointing to a new calendar entity. The problem with this approach is that for all of the other types of WorkEffort, not related to events or calendars, this field would be unused.
  2. Create a parent WorkEffort that has a new workEffortTypeEnumId of type WetCalendar or reuse WetComponent, and add all events as children of this WorkEffort. This would not require any changes to the data model, but not sure if the queries would get messy.
  3. Use WorkEffortCategory. This would not enforce the fact that an event should only belong to a single calendar. Also, there is no category type, so I won’t be able to know which categories are calendars and which are other type of categories. This seems to be the worst option in my opinion.

Currently I would tend to choose option 2.