We don't run a service similar to update.status.net yet. Maybe we should,
but that's for the future to decide. Currently I view it as a callback
that we want to avoid.
noembed.com acts as a proxy for oEmbed requests, but that also means they
get all the links we post on our instances, given that they're used as a
default endpoint.
htmLawed cleans stuff out properly, but there's no very good way right
now to show text/html attachments, since everything gets jumbled up with
our own CSS etc. Best would be an iframe or just a new tab or so.
We're now capable of doing image rotation for thumbnails based on
EXIF orientation data. Also, thumbnails are tracked by filenames and
thus we can delete them from storage when we feel like it.
Conversation trees works pretty bad with the current layout, javascript
etc. So it's best if we separate it and work on it as a side-project. The
oldschool settings are currently being deprecated (or broken out like this).
I'll wait with removing User preferences for oldschool conversation tree,
since that might be reusable data. But I guess it will go in the near future.
This will simplify actions for future development and maintenance
since we can automate much more (such as auto-running show[Ajax|Page])
and handle errors of various kinds. Essentially the same kind of
improvements as Managed_DataObject gives us.
notice.id will give us even really old posts, which were
recently imported. For example if a remote instance had
problems and just managed to post here. Another solution
would be to have a 'notice.imported' field.
It seems it was only used to get a _single_ file attachment from
the posted notice, with no possibility to get multiple attachments.
If one fetches metadata about attachments for the notice, we have
enough data there to fulfill anyone's fetching dreams.
This makes it easier to disable, but remember that you must then
either enable and maintain queue daemons or disable queueing (and
handle whatever remaining queue items are stored in the database)!
We can't say we officially support PostgreSQL, unfortunately. There
are too many database calls with MySQL specific syntax. This would be
desirable for a 2.0 release, but too much work while maintaining 1.x.
The main difficulty is that we're using PEAR::DB which is aging. If
that's exchanged, maybe we could use PDO or something.
