Zach was doing a lot of integer comparisons on the Foreign_link sync
fields. I switched them to use named bitmasks instead. I also switched
the semantics of bit 3 to be the opposite of what Zach had -- I find
lots of double-negatives in a checkbox to be hard to read.
darcs-hash:20080924150834-5ed1f-54cd945f61e43bc06768037c60c1e6180a8feead.gz
Added an inbox and outbox for direct messages.
Factored common code to mailbox.php. Factored common code with
stream.php to personal.php.
darcs-hash:20080916195346-84dde-b5c846f713a970c41fd1b0671cb333e91f3cb920.gz
Add the code to registration to handle invitation codes.
Some edge cases on invitations: is the user already subbed to this
person? Tell them. Is the person already on the system? Sub the user
to them, then, and tell the user.
Add some code to User to auto-sub invitees whenever the email address
changes. Call it from a new registration with an invite code, and also
from confirmaddress.
Some whitespace cleanup in the files touched.
darcs-hash:20080827001927-84dde-b50e5d921ca3f2fb894821730ff93cac09d2ba66.gz
noticesWithFriends is turning out to be one of our most expensive
queries. The join is costly, and this method is hit over and over and
over by desktop clients and other API users.
So, I've added a first pass at caching the results. I store a "window"
of notices -- equal to the first 3 pages of notices, plus one for
pagination -- in the memcached cache. If with-friends notices are
requests, I fetch the whole window out of the cache and grab the slice
requested. If the requested notices are outside the window, we just do
the query. If there's nothing in the cache, we request the window and
store it, then return a slice.
I had to add a NoticeWrapper class that works like DB_DataObject
(well, just the fetch() part...) but just holds an array of notices
instead of a DB cursor.
Finally, saving a new notice blows away the caches for subscribed users.
darcs-hash:20080915065616-84dde-1b1e814c2294498a10b763b779cbb62c3f96aa84.gz
Make "#sanfrancisco", "#SanFrancisco", "#san_francisco", "#San.Francisco", and "#SAN-FRANCISCO" all link to http://identi.ca/tag/sanfrancisco but preserve appearance
darcs-hash:20080901025932-e3c0d-c0a939eaf7e242d88cbcb0d651c9d53718c60a9d.gz
Make "#test", "#Test", and "#tEsT" all preserve appearance but link to the same tag
darcs-hash:20080901001241-e3c0d-b466f35f4f023c6c90a6d2817487c97be9a1bbca.gz
Change common_tag_link to format the tag link based on the setting of $config['site']['fancy']
darcs-hash:20080831233401-e3c0d-4e0e43f5a53a6659c49d65a2b1f2a47c5cdec228.gz
Add another queue handler for the public stream. Should further
parallelize the work of sending out messages.
darcs-hash:20080829181702-84dde-594505aa73d2380b13bd98917b70b02bac597d12.gz
Eventually, the poor xmppdaemon has become overloaded with extra
tasks. So, I've broken it up. Now, we have 5 background scripts, and
more coming:
* xmppdaemon.php - handles incoming XMPP messages only.
* xmppqueuehandler.php - sends notices from the queue out through XMPP.
* smsqueuehandler.php - sends notices from the queue out over SMS
* ombqueuehandler.php - sends notices from the queue out over OMB
* xmppconfirmhandler.php - sends confirmation requests out over XMPP.
This is in addition to maildaemon.php, which takes incoming messages.
None of these are "true" daemons -- they don't daemonize themselves
automatically. Use nohup or another tool to background them. monit can
also be useful to keep them running.
At some point, these might become fork()'ing daemons, able to handle
more than one notice at a time. For now, I'm just running multiple
instances, hoping they don't interfere.
darcs-hash:20080827205407-84dde-97884a12f5f4e54c93bc785bd280683d1ee7e749.gz
