Question - VJOURNAL and X-ALT-DESC support

[rogercreagh]

Does the library support VJOURNAL entries and X-ALT-DESC fields in journal (and calanendar) entries?

[tobixen]

The library supports VJOURNAL, but there are many server implementations that do not support VJOURNAL.

X-ALT-DESC-fields should pass right through the library. Earlier all icalendar data had to be created on the outside of the library, in v0.9 support was added for creating events/tasks/journal entries without first having to create the icalendar data, one can pass parameters like dtstart to set the DTSTART. It's not possible to pass a parameter x_alt_desc when creating events/tasks/journals through the new interface, but it's possible to pass arbitrary data in a parameter ical_fragment.

In the (not yet released) version v0.10, a search method has been added. This search method does not support searching for X-ALT-DESC, but I can consider to add that.

Events/journals/events fetched from the calendar can be accessed either as plain data, a vobject instance or an icalendar instance. I haven't tested, but I beileve the X-ALT-DESC-field can be accessed through those two alternative approaches:

xaltdesc_value = fetched_journal.vobject_instance.vjournal.x_alt_desc
xaltdesc_value = fetched_journal.icalendar_instance.subcomponents[0]['X-ALT-DESC']

[rogercreagh]

Thanks, that is good.

Nextcloud server does support VJOURNAL in its calendar, although it doesn't have any means to display the info yet. Currently you have to manually enable it, but that is quite simple. If no-one gets there first I have a notion to create a simple Journal/Diary app for Nextcloud somewhere in my todo queue.

There is some discussion about how rich text should be best handled for journal items in particular. Journal/diary items are more likely to benefit from rich text as they are likely to be longer. Calendar entries and ToDo's tend to only have short text descriptions and only need minimal tags (bullets, bold italic and possibly links etc).

Markdown is nice and simple but only for somewhat techie users if no markdown viewer or wysiwyg editor is provided.

If markdown is placed in the DESCRIPTION field then it looks ugly for those who don't know markdown (ordinary users) who are using an app that doesn't parse markdown (the default)

HTML provides a richer alternative but really needs a wysiwyg editor for most users. Placing either markdown or html in an X-ALT-DESC field and a vanilla plain tag free text version in the DESCRIPTION is possibly the best way to go so that apps/programmes can always display the plain text, and use the rich alternative if available and they are capable. The issue becomes keeping the two in sync - if an app on one device is not aware of X-ALT-DESC and edits the DESCRIPTION then any app using the rich text option has to intelligently update its X-ALT-DESC. Contrarywise, but slightly simpler, an app using the rich text version has to be able to generate a vanilla text only version after editing without any tags (markdown or html).

The top priority for me is to get a way of displaying journals created on Android using the jtxBoard app to display on a linux laptop (ubuntu) - either using a website (for me, using Joomla3 CMS) with a journal component, or an offline desktop app like RedNoteBook (which I believe also works on Win/Mac). A nextcloud app would do as a third choice.

RedNoteBook is python based so integrating this library could be relatively straightforward. Joomla is php so would be simplest using a php library but so far I've only found an old one. Top of my todo list is to choose one of these options and work on that - a slight preference for Joomla since my php/js is good, but I don't speak python.

[tobixen]

Have you had a look at rfc9073 yet?

That said ... markdown may look ugly for the non-tech user if displayed as-is, but it's at least readable, while HTML isn't. Nicely formatted HTML is ugly but readable for the tech user :-)

[tobixen]

You should learn python, it's easy to learn, relatively easy to write code that can be maintained and understood also by other people, and yet powerful enough to construct just anything. And it's a general purpose language, unlike PHP which originally was made for personal home pages :-) I may be prejudiced, but I believe the popularity of PHP is mostly due to timing ... it was just the perfect language for making home pages during the dot-com-boom, but I don't believe it has a great future, and I believe there will be a glut of people with php programming skills out there for the long-term future ... unlike languages like Fortran and Cobol.

When I started in my previous job in 2004 we were to start a new project from scratch. At that time Perl was my favorite language, and I didn't know Python at all. I'm very happy that my boss decided we should rather do it in Python, in retro-perspective Perl is a very messy language. But it is the Practical Extraction and Reporting Language, so I still use it for such purposes sometimes (generating statistics from a log file, for instance). One of the developers we hired only knew the Pascal programming language when we hired him, he got quite quickly up to speed with Python and became one of our best developers.

At the other hand, Python is already old news - for all I know there may be better languages out there. Rust is supposed to be pretty robust, Go seems to be the goto-language for many new application, and Kotlin is supposed to make developers happy - or so I read. I tried learning Ruby at some point, but I didn't quite see the point with it (at least php is easy to understand - while ruby isn't, at least not for me).

... and what do you want to use journals for, if I may ask? Rarely anyone use them ... it's sort of the correct place to put meeting notes, but then it's needed to link the journal to the meeting event somehow ... now that can be done through a parent/child-relationship, but as the calendar client probably doesn't recognize the journal entry as "meeting notes" it may be pretty moot.

[rogercreagh]

... and what do you want to use journals for, if I may ask? Rarely anyone use them ...

Probably no one uses them in a Calendar context - but consider the plethora of diary/journal/log stand-alone applications across all platforms. They are very well used. Essentially a calendar is focused on future events, a journal is for recording and remembering past events.

Many people use more than one device (eg phone, tablet, laptop, desktop) with diverse operating systems and may want to be able to access their diary/journal on all of them for offline as well as online use. VJOURNAL provides a way of syncing entries across devices and different apps, and standalone apps work offline.

Equally some people want to be able to collaborate on a journal, or share it with others for reading. Of course you can do this with a blog (an online journal) - but that requires you to have a website to host it and to be online to use it - both of which may be inconvenient.

Personally both types of use case apply to me.

I have started work on a component to integrate VJOURNAL items into a blog. I am also using an Android app (jtxBoard) across three different devices - phone, tablet and ebook reader and I would love to have a journal programme on my laptop (ubuntu) which synchronised with the journal. RedNoteBook (which is a python app) is a possible candidate (it also runs on Windows and Mac) but needs a bit of work to integrate a CalDav source. Evolution is another possibility - it already handles VJournal sync in its calendar, but it is (obviously) Calendar centric being an email primarily client.

Various calendar servers handle VJOURNAL items including Nextcloud which I use.

So I think your view that "rarely anyone use them (journals)" is perhaps because you are only thinking of calendars and event scheduling - which is important, but also has little use for creating a diary record - most calendars delete out of date events to save space, whereas a journal, like a blog, will keep everything. Plenty of people like to keep a daily diary.

[rogercreagh]

Have you had a look at rfc9073 yet?

Interesting - that one didn't come up when I originally started looking for the VJOURNAL spec a month or so ago.

It is basically concerned with extending the Calendar uses, but it does add STYLED-DESCRIPTION, which essentially seems to be the same as X-ALT-DESC which was originally introduced by Microsoft. Touch of the not-invented-here perhaps in specifying a new name for the same function. I suppose for maximum compatibility when wanting rich text for a description both will have to be included with identical content - sigh!

Since a diary journal is likely to have longer entries than a calendar event or a todo, it is more likely to benefit from rich text formatting.

I think my preferred direction is to keep DESCRIPTION as vanilla plain text with no markup and use X-ALT-DESC and/or STYLED-DESCRIPTION for an html rich text version.

Both can use a FMTTYPE parameter to specific text/html. You can also use FMTTYPE with the DESCRIPTION, so text/markdown (or text/x-markdown) could be used to specify a format for the "plain text" description. The downside is that the application that is reading the data has to be aware of text/markdown to display it correctly. This is the simplest way to handle simple rich text at the cost of making the description ugly for anyone using a non-markdown aware programme.

Perhaps since VJOURNAL entries are not widely used yet (although they have massive potential) this need not be a problem. (see my other comment for use cases for VJOURNAL)

[tobixen]

Essentially a calendar is focused on future events, a journal is for recording and remembering past events.

Indeed.

I also have my semi-public diary - the "captains log" - which I'm considering to publish in a better way than https://solveig.oslo.no/solveig/diary-2022-07.txt. It has already occurred to me that it could fit into the calendar as VJOURNAL components - see https://github.com/tobixen/calendar-cli/blob/master/NEW_CLI.md#add-an-event-task-or-journal-entry

For the purpose of "captain's log", the VJOURNAL specification is sufficient, but I would also like to log what I've been doing throughout the day and how much time I've spent on it. Quite much if it is already in the system as tasks and events, but as you said - those entities are supposed to focus on future events. I find it frustrating the VJOURNAL is missing DURATION or DTEND, which I need for time tracking - ref https://github.com/tobixen/calendar-cli/blob/master/NEXT_LEVEL.md

Many people use more than one device (eg phone, tablet, laptop, desktop) with diverse operating systems and may want to be able to access their diary/journal on all of them for offline as well as online use. VJOURNAL provides a way of syncing entries across devices and different apps, and standalone apps work offline.

That is correct. For me a git-backed text file sort of gives me everything I need and I have a lot of options for publishing it in a nicer format, but for ordinary people ... yes, even for me it would probably be easier to publish VJOURNAL entries from my cellphone than editing git-backed text files on my cellphone.

I have started work on a component to integrate VJOURNAL items into a blog.

Hmmm ... would be nice for my "captain's log" :-) Though, I may need to attach GPS trails and photos to it as well.

So I think your view that "rarely anyone use them (journals)" is perhaps because you are only thinking of calendars and event scheduling

That's my second-hand observation, as many calendar server implementations just skip supporting it.

[tobixen]

Touch of the not-invented-here perhaps in specifying a new name for the same function. I suppose for maximum compatibility when wanting rich text for a description both will have to be included with identical content - sigh!

Any property starting with X is by definition a non-standard property unlikely to have any meaning outside the local environment or server implementation. Although Microsoft doesn't have the best track record when it comes to adhering to standards, I would expect them (and everybody else) to gradually drop their X-ALT-DESC and introduce full support for the new standard. Hence, any need for duplicating the same content in two properties due to different standards will hopefully not be needed in the long run.