iCalendar Proposal

I've recently been playing around with the idea of exposing my Joplin todos as calendar items. For me this is mostly around my inline-todo plugin, but it can also be applicable to the built-in todo management, or others (e.g. metis).

As an experiment, I wrote a plugin that generates ical format data from Joplin's built-in todo notes, and stores that in an ```ical block. That data is imported into my calendar app by publishing the note and proxying it through a simple webserver that extracts the ical content (I can make this accessible to the devs if they want to play around with it). It works quite well, but I worry that as a general pattern it might be abusive of the publish note feature.

I've just been playing around with it so far, but I think this could be a pretty cool pattern for Joplin, especially if it can be done in a way that can be used by multiple plugins.

I see three avenues for providing iCalendar as a general feature for Joplin users.

  1. Official support in Joplin Desktop/Server
    • This would involve the app having a way for plugins to register new calendar items or calendars (could get messy). which would then be served by Joplin Server
    • Would only be available to Joplin Server users (cloud pro and above)
  2. Using the Publishing feature
    • This is what I've been using to play around with the pattern
    • It works, but is wasteful (fetches a published note, and then removes almost all the content) and requires a separate server
    • Would require each plugin to handle calendar generation and management manually
  3. Upload to an external server
    • Plugins can generate an iCal file and upload them to a basic file server
    • Isn't as wasteful as the publish note case
    • It requires plugins to upload user data to a server, which a lot of users might not appreciate

Realistically, I think Option 3 is the best path forward, and the one I will pursue for my inline-todos plugin. I just wanted to get this out in the open in case the community had any thoughts, or if there is appetite to make this an option in the core of Joplin.

6 Likes

I think that would indeed be useful to to-do managements, but the problem with these solutions is that it's read-only, right? So I could view the to-dos in a different app but changing them wouldn't do anything, if I understand correctly.

To publish things from Joplin Server, one option could also be to attach the ICS file to a note then to access that file only. It's not officially supported but each attached resource has its own URL so that it can be displayed in a published note. Still a bit of hack but maybe better than having to parse the note HTML content. Maybe some API to GET/PUT a file would allow read/write to-dos.

1 Like

Curious why inline-todo is the only of your three published plugins not marked as Recommended in the plugin system.

That's correct. It's a limitation, CalDav could be used instead, but I think read-only iCal get's 80% of the benefit without the complexity. While testing I set the description to the Joplin link, so it's easy to get in and edit the todo. Having mobile plugin support, also means that the iCal can be regenerated without having access to the desktop, which reduces the burden of read-only.

I'll do a mockup to play with this. Parsing the html isn't a huge burden, it just seems wasteful because joplin server needs to prepare html, and then it all get's stripped away later. As long as the file URL is stable, this would be much more elegant.

I think this would still require an external CalDav server to manage the connection with the users calendar app, but would be more manageable than trying to integrate it into Joplin.

Thanks for the discussion @laurent , I'll play around with the file hack.

1 Like

Looks like I can add an attachment using joplin.data.post, but this requires the file to live on disk. That would be fine for desktop, but I don't think it's possible on mobile. So this could be a nice way to save having to load and parse the html over-and-over again, but for my purposes it won't work (for now).

What do you think about the possibility of the resource endpoint accepting base64 encoded file data?

1 Like