gnu-social/classes/statusnet.ini

621 lines
7.2 KiB
INI
Raw Normal View History

2009-08-26 06:56:10 +09:00
[avatar]
profile_id = 129
original = 17
width = 129
height = 129
mediatype = 130
filename = 2
url = 2
created = 142
modified = 384
[avatar__keys]
profile_id = K
width = K
height = K
url = U
[config]
section = 130
setting = 130
value = 2
[config__keys]
section = K
setting = K
2009-08-26 06:56:10 +09:00
[confirm_address]
code = 130
user_id = 129
address = 130
address_extra = 130
address_type = 130
claimed = 14
sent = 14
modified = 384
[confirm_address__keys]
code = K
[consumer]
consumer_key = 130
consumer_secret = 130
2009-08-26 06:56:10 +09:00
seed = 130
created = 142
modified = 384
[consumer__keys]
consumer_key = K
[deleted_notice]
id = 129
profile_id = 129
uri = 2
created = 142
deleted = 142
[deleted_notice__keys]
id = K
uri = U
2009-08-26 06:56:10 +09:00
[design]
id = 129
backgroundcolor = 1
contentcolor = 1
sidebarcolor = 1
textcolor = 1
linkcolor = 1
backgroundimage = 2
disposition = 17
[design__keys]
id = N
[fave]
notice_id = 129
user_id = 129
modified = 384
[fave__keys]
notice_id = K
user_id = K
[file]
id = 129
url = 2
mimetype = 2
size = 1
title = 2
date = 1
protected = 1
filename = 2
modified = 384
[file__keys]
id = N
url = U
2009-08-26 06:56:10 +09:00
[file_oembed]
file_id = 129
version = 2
type = 2
2009-08-28 06:53:16 +09:00
mimetype = 2
2009-08-26 06:56:10 +09:00
provider = 2
provider_url = 2
width = 1
height = 1
html = 34
title = 2
author_name = 2
author_url = 2
url = 2
modified = 384
[file_oembed__keys]
file_id = K
[file_redirection]
url = 130
file_id = 1
redirections = 1
httpcode = 1
modified = 384
[file_redirection__keys]
url = K
[file_thumbnail]
file_id = 129
url = 2
width = 1
height = 1
modified = 384
[file_thumbnail__keys]
file_id = K
url = U
[file_to_post]
file_id = 129
post_id = 129
modified = 384
[file_to_post__keys]
file_id = K
post_id = K
[foreign_link]
user_id = 129
foreign_id = 129
service = 129
credentials = 2
noticesync = 145
friendsync = 145
profilesync = 145
last_noticesync = 14
last_friendsync = 14
created = 142
modified = 384
[foreign_link__keys]
user_id = K
foreign_id = K
service = K
[foreign_service]
id = 129
name = 130
description = 2
created = 142
modified = 384
[foreign_service__keys]
id = K
name = U
[foreign_subscription]
service = 129
subscriber = 129
subscribed = 129
created = 142
[foreign_subscription__keys]
service = K
subscriber = K
subscribed = K
[foreign_user]
id = 129
service = 129
uri = 130
nickname = 2
created = 142
modified = 384
[foreign_user__keys]
id = K
service = K
uri = U
[group_alias]
alias = 130
group_id = 129
modified = 384
[group_alias__keys]
alias = K
[group_block]
group_id = 129
blocked = 129
blocker = 129
modified = 384
[group_block__keys]
group_id = K
blocked = K
[group_inbox]
group_id = 129
notice_id = 129
created = 142
[group_inbox__keys]
group_id = K
notice_id = K
[group_member]
group_id = 129
profile_id = 129
is_admin = 17
created = 142
modified = 384
[group_member__keys]
group_id = K
profile_id = K
[invitation]
code = 130
user_id = 129
address = 130
address_type = 130
created = 142
2009-12-30 15:02:46 +09:00
[inbox]
user_id = 129
notice_ids = 66
[inbox__keys]
user_id = K
2009-08-26 06:56:10 +09:00
[invitation__keys]
code = K
2009-09-16 07:29:14 +09:00
[location_namespace]
id = 129
description = 2
created = 142
modified = 384
[location_namespace__keys]
id = K
[login_token]
user_id = 129
token = 130
created = 142
modified = 384
[login_token__keys]
user_id = K
2009-08-26 06:56:10 +09:00
[message]
id = 129
uri = 2
from_profile = 129
to_profile = 129
content = 34
2009-08-26 06:56:10 +09:00
rendered = 34
url = 2
created = 142
modified = 384
source = 2
[message__keys]
id = N
[nonce]
consumer_key = 130
tok = 2
nonce = 130
ts = 142
created = 142
modified = 384
[nonce__keys]
consumer_key = K
nonce = K
ts = K
[notice]
id = 129
profile_id = 129
uri = 2
content = 34
2009-08-26 06:56:10 +09:00
rendered = 34
url = 2
created = 142
modified = 384
reply_to = 1
is_local = 17
source = 2
conversation = 1
2009-09-16 07:29:14 +09:00
lat = 1
lon = 1
location_id = 1
location_ns = 1
2009-12-12 00:22:56 +09:00
repeat_of = 1
2009-08-26 06:56:10 +09:00
[notice__keys]
id = N
[notice_inbox]
user_id = 129
notice_id = 129
created = 142
source = 17
[notice_inbox__keys]
user_id = K
notice_id = K
[notice_source]
code = 130
name = 130
url = 130
created = 142
modified = 384
[notice_source__keys]
code = K
[notice_tag]
tag = 130
notice_id = 129
created = 142
[notice_tag__keys]
tag = K
notice_id = K
[oauth_application]
id = 129
owner = 129
consumer_key = 130
2010-02-02 05:58:29 +09:00
name = 2
description = 2
icon = 130
source_url = 2
organization = 2
homepage = 2
callback_url = 130
type = 17
access_type = 17
created = 142
modified = 384
[oauth_application__keys]
id = N
2010-02-02 05:58:29 +09:00
name = U
[oauth_application_user]
profile_id = 129
application_id = 129
access_type = 17
token = 2
created = 142
modified = 384
[oauth_application_user__keys]
profile_id = K
application_id = K
2009-08-26 06:56:10 +09:00
[profile]
id = 129
nickname = 130
2009-08-26 06:56:10 +09:00
fullname = 2
profileurl = 2
homepage = 2
bio = 34
2009-08-26 06:56:10 +09:00
location = 2
2009-09-16 07:29:14 +09:00
lat = 1
lon = 1
location_id = 1
location_ns = 1
2009-08-26 06:56:10 +09:00
created = 142
modified = 384
[profile__keys]
id = N
[profile_block]
blocker = 129
blocked = 129
modified = 384
[profile_block__keys]
blocker = K
blocked = K
[profile_role]
profile_id = 129
role = 130
created = 142
[profile_role__keys]
profile_id = K
role = K
2009-08-26 06:56:10 +09:00
[profile_tag]
tagger = 129
tagged = 129
tag = 130
modified = 384
[profile_tag__keys]
tagger = K
tagged = K
tag = K
[queue_item]
XMPP queued output & initial retooling of DB queue manager to support non-Notice objects. Queue handlers for XMPP individual & firehose output now send their XML stanzas to another output queue instead of connecting directly to the chat server. This lets us have as many general processing threads as we need, while all actual XMPP input and output go through a single daemon with a single connection open. This avoids problems with multiple connected resources: * multiple windows shown in some chat clients (psi, gajim, kopete) * extra load on server * incoming message delivery forwarding issues Database changes: * queue_item drops 'notice_id' in favor of a 'frame' blob. This is based on Craig Andrews' work branch to generalize queues to take any object, but conservatively leaving out the serialization for now. Table updater (preserves any existing queued items) in db/rc3to09.sql Code changes to watch out for: * Queue handlers should now define a handle() method instead of handle_notice() * QueueDaemon and XmppDaemon now share common i/o (IoMaster) and respawning thread management (RespawningDaemon) infrastructure. * The polling XmppConfirmManager has been dropped, as the message is queued directly when saving IM settings. * Enable $config['queue']['debug_memory'] to output current memory usage at each run through the event loop to watch for memory leaks To do: * Adapt XMPP i/o to component connection mode for multi-site support. * XMPP input can also be broken out to a queue, which would allow the actual notice save etc to be handled by general queue threads. * Make sure there are no problems with simply pushing serialized Notice objects to queues. * Find a way to improve interactive performance of the database-backed queue handler; polling is pretty painful to XMPP. * Possibly redo the way QueueHandlers are injected into a QueueManager. The grouping used to split out the XMPP output queue is a bit awkward.
2010-01-22 09:42:50 +09:00
id = 129
frame = 66
2009-08-26 06:56:10 +09:00
transport = 130
created = 142
claimed = 14
[queue_item__keys]
XMPP queued output & initial retooling of DB queue manager to support non-Notice objects. Queue handlers for XMPP individual & firehose output now send their XML stanzas to another output queue instead of connecting directly to the chat server. This lets us have as many general processing threads as we need, while all actual XMPP input and output go through a single daemon with a single connection open. This avoids problems with multiple connected resources: * multiple windows shown in some chat clients (psi, gajim, kopete) * extra load on server * incoming message delivery forwarding issues Database changes: * queue_item drops 'notice_id' in favor of a 'frame' blob. This is based on Craig Andrews' work branch to generalize queues to take any object, but conservatively leaving out the serialization for now. Table updater (preserves any existing queued items) in db/rc3to09.sql Code changes to watch out for: * Queue handlers should now define a handle() method instead of handle_notice() * QueueDaemon and XmppDaemon now share common i/o (IoMaster) and respawning thread management (RespawningDaemon) infrastructure. * The polling XmppConfirmManager has been dropped, as the message is queued directly when saving IM settings. * Enable $config['queue']['debug_memory'] to output current memory usage at each run through the event loop to watch for memory leaks To do: * Adapt XMPP i/o to component connection mode for multi-site support. * XMPP input can also be broken out to a queue, which would allow the actual notice save etc to be handled by general queue threads. * Make sure there are no problems with simply pushing serialized Notice objects to queues. * Find a way to improve interactive performance of the database-backed queue handler; polling is pretty painful to XMPP. * Possibly redo the way QueueHandlers are injected into a QueueManager. The grouping used to split out the XMPP output queue is a bit awkward.
2010-01-22 09:42:50 +09:00
id = K
2009-08-26 06:56:10 +09:00
[related_group]
group_id = 129
related_group_id = 129
created = 142
[related_group__keys]
group_id = K
related_group_id = K
[remember_me]
code = 130
user_id = 129
modified = 384
[remember_me__keys]
code = K
[remote_profile]
id = 129
uri = 2
postnoticeurl = 2
updateprofileurl = 2
created = 142
modified = 384
[remote_profile__keys]
id = K
uri = U
[reply]
notice_id = 129
profile_id = 129
modified = 384
replied_id = 1
[reply__keys]
notice_id = K
profile_id = K
[session]
id = 130
session_data = 34
created = 142
modified = 384
[session__keys]
id = K
[sms_carrier]
id = 129
name = 2
email_pattern = 130
created = 142
modified = 384
[sms_carrier__keys]
id = K
name = U
[subscription]
subscriber = 129
subscribed = 129
jabber = 17
sms = 17
token = 2
secret = 2
created = 142
modified = 384
[subscription__keys]
subscriber = K
subscribed = K
[token]
consumer_key = 130
tok = 130
secret = 130
type = 145
state = 17
verifier = 2
verified_callback = 2
2009-08-26 06:56:10 +09:00
created = 142
modified = 384
[token__keys]
consumer_key = K
tok = K
[user]
id = 129
nickname = 2
password = 2
email = 2
incomingemail = 2
emailnotifysub = 17
emailnotifyfav = 17
emailnotifynudge = 17
emailnotifymsg = 17
emailnotifyattn = 17
emailmicroid = 17
language = 2
timezone = 2
emailpost = 17
jabber = 2
jabbernotify = 17
jabberreplies = 17
jabbermicroid = 17
updatefrompresence = 17
sms = 2
carrier = 1
smsnotify = 17
smsreplies = 17
smsemail = 2
uri = 2
autosubscribe = 17
urlshorteningservice = 2
inboxed = 17
design_id = 1
viewdesigns = 17
created = 142
modified = 384
[user__keys]
id = K
nickname = U
email = U
incomingemail = U
jabber = U
sms = U
uri = U
[user_group]
id = 129
nickname = 2
fullname = 2
homepage = 2
description = 34
2009-08-26 06:56:10 +09:00
location = 2
original_logo = 2
homepage_logo = 2
stream_logo = 2
mini_logo = 2
design_id = 1
created = 142
modified = 384
[user_group__keys]
id = N
nickname = U
[user_openid]
canonical = 130
display = 130
user_id = 129
created = 142
modified = 384
[user_openid__keys]
canonical = K
display = U
[user_openid_trustroot]
trustroot = 130
user_id = 129
created = 142
modified = 384
[user_openid__keys]
trustroot = K
2009-12-29 06:59:03 +09:00
user_id = K
[user_location_prefs]
user_id = 129
share_location = 17
created = 142
modified = 384
[user_location_prefs__keys]
user_id = K