Added the following FIXME:
How should a Twitter user get their Inbox filled with foreign tweets?
Every imported Twitter user has a profile in the Profile table, so we
could setup a Subscription entry for each of those, meaning they get
collected in the InboxNoticeStream... But this would mean a lot of
unnecessary entries and listings that generally just point to the
locked down Twitter service.
Let's figure out a good relation so we can connect any profile to any
imported foreign notice, so it shows up in the "all" feed.
Also cleaned up and made typing stricter for the stream, so only
profiles can be submitted. This reasonably also means we can create
"inbox" or "all" streams for foreign profiles as well using the same
stream handler (but of course only for messages we already know about).
To avoid looking up posts for a long time in a large notice database,
the lookback period for the inbox is no longer than the profile creation
date. (this matches the behaviour of Inbox)
Inbox class can probably be removed now.
There was a problem with (specifically at least) PuSHpress for
Wordpress. A previous attempt to perform a DB transaction backfired
because the remote side could connect to the callback before our
commit had gone through.
I take full responsibility for introducing the bug in the first place :)
This will work without much extra effort because there will always be
more notices (higher value) than conversations (so no collisions).
But please run upgrade.php to avoid having an autoincrement id on
conversation table.
Installations using code after 2014-03-01 will have identical
conversation IDs to the initial (conversation root) notice IDs. This
will not affect older installations, which will have very different
values.
require_once lines were required since _plugins_ don't __autoload
Also, Realtime would load the wrong URL for css/js since $this->name()
returns get_class($this) instead of the calling class' __CLASS__.
Many of the microapps are pretty javascript dependant, but at least
we should allow users to get to the new notice field without allowing
javascript to run in the browser. :)
Minutely will NOT necessarily run by the minute, because it depends on
site visitors. Busy sites will be able to do this, but sites where the
visitors (or search engine stuff or api calls) are more than a minute
apart, the interval will be much larger.
Among other things (such as permanent subscriptions), Pubsubhubbub 0.4
removed the "sync" verification method. This means that any incoming
PuSH subscription requests that follow the 0.4 spec won't really
_require_that we handle it as a background process, but if we were to
try direct verification of the subscription - and fail - there's no way
we could pick up the ball again. So _essentially_ we require background
processing with retries.
This means we must implement something like the "poorman cron" or
similar, so background processing can be handled
on-demand/on-site-visit. This is how Friendica, Drupal etc. handles it
and is necessary for environments where we can't run separate queue
daemons.
When the poorman-cron-ish thing is implemented, auto-renewal will work
for all users.
PuSH 0.4 spec:
https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html
More on PuSH 0.4 release (incl. breaking changes):
https://groups.google.com/forum/#!msg/pubsubhubbub/7RPlYMds4RI/2mIHQTdV3aoJ
This is more of a proof of concept and will likely not stay in exactly
this form. We should reasonably deliver the entire notice upon webfinger
querying.
If you're using XMPP by setting $config['xmpp'][*] then you should do:
addPlugin('Xmpp', $config['xmpp']);
because setting it directly in $config[''] won't do anything.
Also, default resource for XMPP is now 'gnusocial'. If you want something
more random, set it in your addPlugin config array.
Also removed the entirely unused saveGroups function.
Now avoiding multiGet and using listFind in Profile->getGroups()
so we don't have to deal with ArrayWrapper.
