Sprints/PIM/2023: Difference between revisions

From KDE Community Wiki
Line 40: Line 40:
** A single QNAM instance can then be held by the DavManager singleton, API to provide an external one isn't needed initially (and we probably won't want it ever, this opens a can of worms in term of API safety).
** A single QNAM instance can then be held by the DavManager singleton, API to provide an external one isn't needed initially (and we probably won't want it ever, this opens a can of worms in term of API safety).


=== KCalendarCore::Calendar interface changes ===
=== KCalendarCore::Calendar async change operations ===


Use-case: Zanshin using KCalendarCore::Calendar with the calendar plugins instead of Akonadi-specific models.
Use-case: Zanshin using KCalendarCore::Calendar with the calendar plugins instead of Akonadi-specific models.
Line 53: Line 53:
* Can be phased in small steps and possible even in an API-compatible way.
* Can be phased in small steps and possible even in an API-compatible way.
* Far more realistic in terms of effort.
* Far more realistic in terms of effort.
=== KCalendarCore::Calendar API review ===
Areas in need of a closer look:
* pseudo-I/O API: isSaving(), save(), close(), reload(), ...
** base implementations are usually non functional dummys
** semantics make little sense in an Akonadi or Android world
** isSaving() looks entirely unused
* Notebook API
** we don't even know what that is, not covered in any RFC and apparently existing entirely in memory
** unused in our code, but possibly something used by Sailfish (https://github.com/sailfishos/mkcal/blob/master/src/notebook.h ??)
* Filtering capability
** Duplicates parts of the read API (raw vs non-raw)
** Conceptually something that rather belongs in a proxy-calendar on top
** Direct calls to filtered read API in any of the existing Calendar sub-classes would make a transition to the proxy approach difficult though.
* Relations API
** seems duplicated in Akonadi::CalendarBase, a possible reason for this is lacking change notifications in that base class?
** setup/removeRelations should likely be protected? currently only used by MemoryCalendar
** functionality is needed though for hierarchical todos


=Sprint Schedule=
=Sprint Schedule=

Revision as of 20:39, 31 March 2023

Venue

  • Artilect Fablab Toulouse
  • 10 rue Tripière – 31000 Toulouse - France
  • https://artilect.fr/ (website in French only)

Agenda

Add topics we should discuss:

  • KF6-based PIM:
    • blocking issues?
    • release timeline, branching
    • Remaining issues with replacing the Kross-based account wizard
    • Retiring the Kolab resource in favor of CalDav/CardDav?
    • Retiring the mixed maildir resource in favor or "real" maildir?
  • QML compatibility
    • QML APIs for PIM libraries
    • upstreaming QML API from Kalendar to KF
  • PIM Frameworks in KF6
    • KDAV without KIO HTTP?
    • KCalendarCore custom/non-standard properties API
  • PIM Libraries/Dependencies
    • KMailTransportAkonadi folding in akonadi-mime?
    • the last KWallet use in KMailTransport - how can we get rid of that?
    • moving the remaining things needed for Kalendar from eventviews and calendarsupport down to akonadi-calendar
    • can we reverse the akonadi-contact -> contacteditor dependency?

Notes

QNAM port of KDAV

  • we want this given the state of KIO HTTP, the complexity of KIO HTTP deployment and due to not needing anything KIO HTTP provides over QNAM for the most part
  • the good news: KIO is not leaking to the outside in the KDAV API, we can switch the implementation whenever we want
  • migration plan
    • complete the test coverage using FakeServer scenarios, at least covering the three DAV verbs used here (PROPFIND, PROPPATCH, REPORT), ideally also the HTTP verbs beyond GET. Note that different paths are taken depending on the protocol (CardDav vs CalDav), so we need to consider both for the tests.
    • A single QNAM instance can then be held by the DavManager singleton, API to provide an external one isn't needed initially (and we probably won't want it ever, this opens a can of worms in term of API safety).

KCalendarCore::Calendar async change operations

Use-case: Zanshin using KCalendarCore::Calendar with the calendar plugins instead of Akonadi-specific models.

Option 1:

  • Make modifying methods on Calendar return something job-like, and thus make the API fully async.
  • That's the right approach on paper...
  • ... but very invasive. Likely not realistic for KF6.

Option 2:

  • Add additional API for registering an error handler and possibly more change notification signals.
  • Can be phased in small steps and possible even in an API-compatible way.
  • Far more realistic in terms of effort.

KCalendarCore::Calendar API review

Areas in need of a closer look:

  • pseudo-I/O API: isSaving(), save(), close(), reload(), ...
    • base implementations are usually non functional dummys
    • semantics make little sense in an Akonadi or Android world
    • isSaving() looks entirely unused
  • Filtering capability
    • Duplicates parts of the read API (raw vs non-raw)
    • Conceptually something that rather belongs in a proxy-calendar on top
    • Direct calls to filtered read API in any of the existing Calendar sub-classes would make a transition to the proxy approach difficult though.
  • Relations API
    • seems duplicated in Akonadi::CalendarBase, a possible reason for this is lacking change notifications in that base class?
    • setup/removeRelations should likely be protected? currently only used by MemoryCalendar
    • functionality is needed though for hierarchical todos

Sprint Schedule

  • April 1/2, 2023
  • It's possible to show up to the venue on the Friday afternoon, I will be there to greet the early birds

Travel Reimbursement

Attendance

  • Kevin Ottens
  • Ingo Klöcker
  • Volker Krause
  • Laurent Montel
  • Carl Schwan

Hotel

  • Plenty of options in the area on all price ranges, living there I didn't get to try them though...
  • Proposed hotel is "Hôtel de France", seems to be one of those smaller and a bit dated but clean options
  • Pricing seems a bit cheaper directly on their website: https://hotel-france-toulouse.com/ (also available through booking.com for those who prefer that)

Arrival and departure times

  • Ingo: arriving 5:54 on Friday (by night train), departing 22:18 on Sunday (by night train)
  • Laurent: arriving 16:55 on friday (airport), departing 20:20 on sunday (airport)
  • Carl: arriving 7:07 on Saturday (by night train), departing 22:18 on Sunday (by night train)
  • Volker: arriving 10:2913:24 on Friday by train, departing 17:19 on Sunday by train

Restaurants

  • Friday dinner: Le Maharaja - 46, rue Peyrolières - 31000 Toulouse
  • Saturday lunch: La Faim des Haricots (take away)
  • Saturday dinner: Jalapeños (delivery)
  • Sunday lunch: La Faim des Haricots (take away)

Report

Draft of report:

KDE Itinerary compatible

Can be copy/pasted into KDE Itinerary:

{
    "@context": "http://schema.org",
    "@type": "EventReservation",
    "reservationFor": {
        "@type": "Event",
        "name": "KDE PIM Sprint 2023",
        "startDate": "2023-04-01T10:00:00+02:00",
        "endDate": "2023-04-02T18:00:00+02:00",
        "location": {
            "@type": "Place",
            "name": "Artilect Fablab Toulouse",
            "address": {
                "@type": "PostalAddress",
                "addressCountry": "FR",
                "addressLocality": "Toulouse",
                "postalCode": "31000",
                "streetAddress": "10 rue Tripière"
            },
            "geo": {
                "@type": "GeoCoordinates",
                "latitude": 43.6017920,
                "longitude": 1.4428500
            }
        }
    }
}