1. 26 Feb, 2020 1 commit
  2. 02 Sep, 2018 1 commit
  3. 19 Jan, 2018 1 commit
    • Daniel Vrátil's avatar
      Use QIODevice::readyRead() to wait for incoming data · 2058ae6c
      Daniel Vrátil authored
      Also avoid any reading code to be executed in a slot connected to
      readyRead() signal because Qt will not emit readyRead() signal
      recursively. This change is needed to make Akonadi work on Windows,
      because the blocking QLocalSocket::waitForReadyRead() does not work
      reliably there.
      On Linux QLocalSocket::waitForReadyRead() is used internally only
      in DataStream for performance reasons. On Windows DataStream will
      internally instantiate a QEventLoop and wait for the readyRead()
      signal, which is more expensive, especially since DataStream can
      get into the wait state multiple times while reading a single
  4. 23 Apr, 2017 1 commit
    • Daniel Vrátil's avatar
      Generate Protocol from an XML specification (ABI break) · 5535d6e5
      Daniel Vrátil authored
      Instead of maintaining 12k lines of hand-written protocol code, we
      specify the protocol in an XML and use a custom-written generator
      that generates the code for us.
      It's not only much easier to modify the protocol - we only need to
      change a single thing in the XML instead of touching several places
      of the implementation - but it's also much safer, as there's less
      risk of accidentally introducing a bug in the code.
      The major difference between the original hand-written code and the
      generated code is that we no longer use QSharedDataPointer and virtual
      methods in the Private classes, but instead all members are directly
      in the command clas with most getters and setters inlined. This means
      that copying commands is quite costly, so we pass them around as
      QSharedPointers or const references. This should give us a tiny little
      bit more performance.
  5. 02 Jan, 2017 1 commit
  6. 01 Jan, 2017 1 commit
  7. 15 Aug, 2016 2 commits
    • Daniel Vrátil's avatar
      Create a per-type ChangeNotification Protocol command · 040ce64b
      Daniel Vrátil authored
      Different entity types have different data, so sharing a single
      structure to describe changes in all entities is limiting. Having
      a single structure made sense when we only had Items and Collections
      which share most of the attributes and it was also easier to expose
      this via DBus.
      Now we are no longer limited by DBus so we can afford having a
      different Protocol command for each notification type. This will be
      most important when we introduce SubscriberChangeNotification, as
      subscriber changes would otherwise be hard to map onto the legacy
      ChangeNotification and is also the first step towards Notification
    • Daniel Vrátil's avatar
      Make AkonadiServer QObject, manage multiple QLocalServers for different purposes · 0e478e2b
      Daniel Vrátil authored
      This creates so called CommandServer and NotificationServer, both
      QLocalServer listening using named pipes (this is a move away from
      a socket file to avoid having multiple files).
      Each new connection on CommandServer makes AkonadiServer to instantiate
      new Connection object as normally. For NotificationServer each new
      connection is handed over to NotificationManager, which will deal with
  8. 23 Apr, 2016 1 commit
  9. 05 Sep, 2015 1 commit
  10. 11 Aug, 2015 1 commit
  11. 10 Aug, 2015 1 commit
  12. 11 Jun, 2015 2 commits
    • Daniel Vrátil's avatar
      Fix ListHandlerTest, improve related Protocols and fix some porting bugs in LIST handler · 575078d1
      Daniel Vrátil authored
      The testListEnabled benchmark shows the same time as with old ASAP, which is slightly
      disappointing, but I'm sure there's a lot of room for improvement.
    • Daniel Vrátil's avatar
      Change they way commands are serialized into datastream · 439d28ec
      Daniel Vrátil authored
      Unfortunatelly QDataStream has no way of waiting for complete data to be
      available in the underlaying QIODevice, so we need to serialize the command
      in two levels: we serialize the entire command into a QByteArray and then
      we write the size of this QByteArray, followed by the data into the actual
      socket. By sending the size of the serialized data first we allow the deserialization
      code to ensure it reads the entire data (and waits for more if they are not
      available in the QIODevice at once).
      This fixes sending very large commands as well as sequences of commands at
      some cost to performance, but that's something we can look into optimizing
      later on.
  13. 10 Jun, 2015 1 commit
  14. 08 Jun, 2015 2 commits
  15. 03 Jun, 2015 1 commit
  16. 31 May, 2015 1 commit
  17. 27 Aug, 2014 1 commit
  18. 10 Aug, 2014 3 commits
  19. 31 Jul, 2014 1 commit
  20. 23 May, 2014 1 commit
  21. 22 May, 2014 1 commit
  22. 19 May, 2014 1 commit
    • Daniel Vrátil's avatar
      Rework the Fake testing infrastructure to be more like server-client · 8fb7ab10
      Daniel Vrátil authored
      This is inspired by FakeServer from KIMAP, where server (a thread) is given a
      scenario and it compares whether requests from client match the scenario and
      sends back replies from the scenario, except here the roles are switched and
      the scenario is played by client, which verifies whether server responds
      correctly to it's commands.