Solve the calendar problem once and for all

[RubenVerborgh]

Pitch

What if we never had to use Doodle again?

Desired solution

• We currently have Knoodle, which computes an agenda match in-browser
• Let's ensure that every part of the code functions in every part of the network (server / client / middleware)
• Let's make it super easy to connect to existing calendars and create derived calendars
  • Can we define them in RDF?
• Let's make a browser plugin that autofills Doodle polls. For real.
• Get the whole world on there.
  • In particular @IDLabResearch people who have complex calendars

Acceptance criteria

• The calendar service can run on an independent node
• I can give it a list of my calendar feeds
• It can output derived versions (free/busy, union, intersection) of these feeds behind access control
• A browser plugin fills in Doodle polls based on this service

Pointers

• https://github.com/KNowledgeOnWebScale/knoodle
• Ask for a live demo of @RubenVerborgh's calendar and slots system

Challenges

• External service stores calendar in pod #68
• Fill in Doodle polls based on calendar data in pod #95

[pheyvaer]

Another pointer: Solid Calendar Store allows publishing aggregate/transformed calendars (as ICS and RDF) based on existing ICS feeds. This works directly with CSS.

[pheyvaer]

@RubenVerborgh You were trying some things on your side. What is the status of that?

[bjdmeest]

I have a 'my previously entered Doodles to ical'-script (verrrrry brittle), happy to hack smth together! https://github.com/bjdmeest/my-doodle-options

[github-actions]

Please provide a status update about this challenge. Every ongoing challenge needs at least one status update every 2 weeks. Thanks!

[pheyvaer]

@RubenVerborgh How is it going with your calendar setup and integrating it with KNoodle.
@bjdmeest I think for that we need to have the browser plugin to fetch data from a pod and inject data in the current Web page to think the Doodle boxes, no?

[bjdmeest]

@pheyvaer yeah indeed, sounds about right

[jeswr]

Let's make it super easy to connect to existing calendars and create derived calendars

This came up when I was talking to the ewada team today about the Calendar app that they are working on. Currently they are using the solid calendar store but this means that:
a) the app will not work on an aribtrary solid pod, and
b) that they cannot define the calendars they want to import from the app.

Is there a way of using orchestrators to fix these two problems?

cc @renyuneyun

[pheyvaer]

These are valid remarks!

a) The next step would indeed be to let this happen by an orchestrator: the orchestrator reads the calendar data from the original location (for example, Google Calendar) and stores in the user's pod using only methods that are Solid-compatible so it works with every Solid pod regardless of its implementation.

b) I don't understand what you mean with that. Can you maybe explain with an example?

[jeswr]

b) I don't understand what you mean with that. Can you maybe explain with an example?

Users should have an interface within their calendar application where they can add/remove those 3rd party calendars which they want to import into their 'solid calendar'. In order to do this, the application needs to be able to control the file which declares those 3rd party calendars they want to integrate.

This is currently not possible as the 3rd party calendars are part of the components.js file (https://github.com/KNowledgeOnWebScale/solid-calendar-store/blob/b6c8388122e0d8917579d5adbd64d13dc48eb862/test/configs/alternate-config.json#L11-L12) and hence can only be defined before starting the server.

[pheyvaer]

I got it now. If we go with an orchestrator, then the burden of configuring that would also move to that orchestrator. So the orchestrator probably needs an app then to configure it.

[github-actions]

Please provide a status update about this challenge. Every ongoing challenge needs at least one status update every 2 weeks. Thanks!

[pheyvaer]

See #68

[github-actions]

Please provide a status update about this challenge. Every ongoing challenge needs at least one status update every 2 weeks. Thanks!

[pheyvaer]

@RubenVerborgh I'm thinking about changing this to a scenario where one of the challenges is #68. Do we need then a separate challenge for a plugin that fills in a Doodle? Doodle is mentioned in the pitch, but not in the acceptance criteria, so not a 100% sure it should be tackled.

[github-actions]

Please provide a status update about this challenge. Every ongoing challenge needs at least one status update every 2 weeks. Thanks!

[RubenVerborgh]

@pheyvaer Let's indeed split them up, as you propose above.