Add “Notes” field to tags. about tasks HOT 9 CLOSED

   I see. I expected you'd store the data in a database. After all, aren't the relevant RFCs primarily designed for data transmission? I'm certain that Google doesn't store contact data in VCF form on its servers, for instance.

The data is stored in a database, but the storage format just looks like iCal (more or less). And if the parameters you ask for cannot be synchronized or even transmitted, what use does it have to store them in whatever database. No CalDAV client (and the Tasks app is just a CalDAV client as well) would be able to show the data. I don't care in whatever format Google stores its data, if they cannot serve it via a common format, no standard client will show it.

It's FRs like this which to me demonstrate the problems inherent with your current design. I'd like to file an issue requesting that the entire storage framework be restructured, but it seems like you only keep feasibly actionable (rather than merely potentially desirable) issues open, so I suppose I can't, and thus this shall need to remain closed. Thanks for the explanation, @raimund-schluessler.

I am happy that someone finally found what makes Nextcloud CalDAV and Tasks so terrible and looking forward to you fixing it. This is OpenSource software, pull requests and working code are always welcome. But please bear in mind, this is a CalDAV client and we will only implement what the CalDAV standard supports. If you are not happy about that, feel free to use another software of your choice.

By the way, the CalDAV server Nextcloud uses (hence, the one with the "problems inherent with our current design") is sabre/dav. I am sure they are happy to hear your complains about their insufficient design decisions.

from tasks.

@raimund-schluessler, I can only estimate from your second paragraph that you believe that I meant to imply some sort of passive aggression in my text. I meant not. Although I didn't protect what I stated against incorrectness which utilizing "potentially" in some cases would have done, I regardless consider you the more competent user here, so if you tell me how the database is managed is is ideal, I shall believe that. I thank you for the explanations. I hope I've dissuaded any possibility of such inference in the future, if I am correct. Apologies.

Sorry if I misinterpreted this. Dealing with users can be frustrating as an OpenSource developer, because much is demanded and usually only little is rewarded or even contributed.

I don't know if the database management is ideal, but it gets the job done. The entries are stored in a way that they can be directly served via CalDAV and don't need to be constructed from different database fields. Of course, this limits what can be stored in the database to what can be synced by CalDAV / iCal. But that is ok, since we aim to be a CalDAV client, nothing more or less.

Regardless, I do still disagree on the singular point that merely because a feature cannot be federated, it should not be implemented. Why do you appear to disagree on that point? Considering how most ActivityPub servers (for instance) allow their clients to consume usually solely a portion of the functionality available due to each server type's differing purposes and APs reasonable current limitations, I don't see why a CalDAV client would differ. It's not like it would be vendor lock-in were it in good faith?

If there was a newer CalDAV version allowing to do this (potentially not offering the feature to older clients), it would be one thing. But there simply is none. We could only implement or own solution on top of what CalDAV offers, not compatible with any other client and prone to break due to what other clients might do with the CalDAV data. Given the niche that this feature would be used in, it is simply not worth the effort. Especially compared to other features, or just simply keeping the app running with newer Nextcloud version. After all, I am the only one working on Tasks, and my freetime is limited.

from tasks.

We use the iCalendar standard defined in RFC5545 and this does not implement a description for categories, see https://datatracker.ietf.org/doc/html/rfc5545#section-3.8.1.2. Hence, we have no way of implementing a description for categories / tags in a standard conformant way.

Also, no other part of Nextcloud offers a description for tags.

from tasks.

#2395 (comment)

@raimund-schluessler, it's not like you store the actual calendar data in an iCal file - that's merely for transmission, surely? I'm only asking for it to be available on NextCloud Tasks if it can't be reliably synchronized. I understand adhering to a standard for functionality which is standardized, but I find it very difficult to believe that there is any desire within NextCloud to limit itself to solely providing what certain RFCs define.

from tasks.

Well, this is exactly how the CalDAV server provided by Nextcloud server, and basically every CalDAV server works. The VTODOs are stored in the iCal format and we have no way to sync or store parameters not supported by it.

We could of course add or own backend managing tags, but this would run outside the CalDAV protocol and would not be synced to other CalDAV clients.

from tasks.

#2395 (comment)

1. Well, this is exactly how the CalDAV server provided by Nextcloud server, and basically every CalDAV server works. The VTODOs are stored in the iCal format and we have no way to sync or store parameters not supported by it.

   I see. I expected you'd store the data in a database. After all, aren't the relevant RFCs primarily designed for data transmission? I'm certain that Google doesn't store contact data in VCF form on its servers, for instance. It's FRs like this which to me demonstrate the problems inherent with your current design. I'd like to file an issue requesting that the entire storage framework be restructured, but it seems like you only keep feasibly actionable (rather than merely potentially desirable) issues open, so I suppose I can't, and thus this shall need to remain closed. Thanks for the explanation, @raimund-schluessler.

2. We could of course add or own backend managing tags, but this would run outside the CalDAV protocol and would not be synced to other CalDAV clients.

   As aforementioned, that wouldn't whatsoever prevent synchronization. Usually, data transferral formats, be they vCard, iCal, JSON or XML, are independently converted to when necessary rather than utilized as a method of storage, not least because of how slow manipulating such data usually is. To my knowledge, anyway.

from tasks.

#2395 (comment)

Regardless, @raimund-schluessler, you should re-close this as unplanned rather than completed.

from tasks.

#2395 (comment)

@raimund-schluessler, I can only estimate from your second paragraph that you believe that I meant to imply some sort of passive aggression in my text. I meant not. Although I didn't protect what I stated against incorrectness which utilizing "potentially" in some cases would have done, I regardless consider you the more competent user here, so if you tell me how the database is managed is is ideal, I shall believe that. I thank you for the explanations. I hope I've dissuaded any possibility of such inference in the future, if I am correct. Apologies.

Regardless, I do still disagree on the singular point that merely because a feature cannot be federated, it should not be implemented. Why do you appear to disagree on that point? Considering how most ActivityPub servers (for instance) allow their clients to consume usually solely a portion of the functionality available due to each server type's differing purposes and APs reasonable current limitations, I don't see why a CalDAV client would differ. It's not like it would be vendor lock-in were it in good faith?

from tasks.

#2395 (comment)

@raimund-schluessler, I understand. If I were to ever propose a PR to add this attribute, would it be rejected on that basis? If so, I suppose I better start learning how to write RFCs!

from tasks.