External service stores calendar in pod

[pheyvaer]

Pitch

At the moment it's possible to request a calendar from a CSS instance through the use of a store. But this solution is coupled to the implementation of CSS. A better solution would be to have an external service that reads the original calendar and stores it in a pod using only the methods specified by Solid.

Desired solution

This can be a CLI tool that is executed periodically with a cron job on a server. Let's make this as lightweight as possible. Thus, do not use unnecessary frameworks for this.

Acceptance criteria

• I install a service on a server, which can be different from the server that is running my pod.
• I configure the service to read data from my ICS feed.
• I configure the service to write the data to a specific resource on my pod.
• I configure how often the calendar data is updated on the pod.
• I log in with my WebID in the service so that it can write to private resources.
• The service supports these manipulations.

Pointers

• https://communitysolidserver.github.io/CommunitySolidServer/5.x/usage/client-credentials/
• You should be able to reuse parts of the code of this store.

Scenarios

• Solve the calendar problem once and for all #2

[RubenVerborgh]

More specifically, can we develop a universal technique (applied to the calendar use case) such that the 3 situations below can be implemented with the same code?

• the calendar is a backend store to the pod
• the calendar is an agent that writes to the pod (possibly with a read hook to write at the right time)
• the calendar is an agent that has its own store; the pod replies by linking to it

@pietercolpaert has a single diagram that can be interpreted as the above 3 cases.

[jeswr]

FWIW I don't see the read hook as just an optimisation in the second case. It is necessary to guarantee consistency between to pod and the calendar whenever an app reads from the pod.

[RubenVerborgh]

I don't see the read hook as just an optimisation in the second case

Ack. With "an agent that writes to the pod", I meant to say "an agent that writes to the pod every time there is a change in the backend". So if my calendar changes 1000 times, but there is only 1 read in that period, there would still be 1000 writes, 999 of which would be unnecessary. So there, read hooks are a bandwidth optimization.

However, that does not account for cases where there is no defined update frequency or notification. I've adjusted the language above

[pheyvaer]

@RubenVerborgh Yes, it makes sense to look at other techniques and ideally it can be done with the same code, but for the sake of keeping challenge concise and solvable within 2-3 months I would stick to only one technique: "the calendar is an agent that writes to the pod". The other two techniques and optimizations are then put into separate challenges. What do you think?

[RubenVerborgh]

Well, the objective should really be to find 1 method that works for all cases. I'm fine with this challenge only addressing 1 case, but the solution should be generic or it doesn't make sense to pursue it.

[pheyvaer]

Sure, the fact that we use calendar data should be confined to only one part of the code and the rest of the code should ideally be readily available to be reused for other data as well.

[pheyvaer]

@RubenVerborgh Are changes still needed here?

[RubenVerborgh]

Okay for me if the method is portable to other cases.

[renyuneyun]

Comment as required to allow mentioning me :)

[github-actions]

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

[pheyvaer]

The code that @zimengzhou1 and @renyuneyun created is here, specifically in the folder core.

[github-actions]

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

[pheyvaer]

You find the report for this challenge here.