Skip to content
Extraits de code Groupes Projets
  1. sept. 29, 2016
  2. sept. 27, 2016
  3. sept. 26, 2016
  4. sept. 25, 2016
  5. sept. 24, 2016
  6. sept. 23, 2016
  7. sept. 22, 2016
  8. sept. 21, 2016
  9. sept. 20, 2016
    • Eugen Rochko's avatar
      Fix #24 - Thread resolving for remote statuses · 4bec6138
      Eugen Rochko a rédigé
      This is a big one, so let me enumerate:
      
      Accounts as well as stream entry pages now contain Link headers that
      reference the Atom feed and Webfinger URL for the former and Atom entry
      for the latter. So you only need to HEAD those resources to get that
      information, no need to download and parse HTML <link>s.
      
      ProcessFeedService will now queue ThreadResolveWorker for each remote
      status that it cannot find otherwise. Furthermore, entries are now
      processed in reverse order (from bottom to top) in case a newer entry
      references a chronologically previous one.
      
      ThreadResolveWorker uses FetchRemoteStatusService to obtain a status
      and attach the child status it was queued for to it.
      
      FetchRemoteStatusService looks up the URL, first with a HEAD, tests
      if it's an Atom feed, in which case it processes it directly. Next
      for Link headers to the Atom feed, in which case that is fetched
      and processed. Lastly if it's HTML, it is checked for <link>s to the Atom
      feed, and if such is found, that is fetched and processed. The account for
      the status is derived from author/name attribute in the XML and the hostname
      in the URL (domain). FollowRemoteAccountService and ProcessFeedService
      are used.
      
      This means that potentially threads are resolved recursively until a dead-end
      is encountered, however it is performed asynchronously over background jobs,
      so it should be ok.
      4bec6138
Chargement en cours