-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Any progress on this front? How can I help? :)
On 6/10/09 12:33 AM, Pedro Melo wrote: > Hi, > > Some pre-meeting ideas where sent to the mailing list: > > * http://mail.jabber.org/pipermail/operators/2009-May/000584.html > * http://mail.jabber.org/pipermail/operators/2009-June/000601.html > > > 1. Radar > > The idea of having a site that lists domains that have a XMPP service, > and associated stats > > (Ed: during the discussion the notion of radar and monitoring service > seemed to merge, not sure if it should merge) > > Domains could be added by anybody or by any means to the radar DB, the > information collected is publicly available on a web site. > > Mickael is worried about spam, if the database is available publicly or > if the service allows listing of domains. The issue of database > ownership was raised but not discussed. > > Current consensus is: > > * collect information from all domains found: how to find new domains > was not discussed though; > * publish information on the radar site, but allow for opt-out: methods > for opt-out where not discussed. > > => Possible next steps: > > * gather suggestions about how to collect new domains; > * methods to opt-out. > > The radar should have some way to include information (description, > URLs, logo) in the domain/service page. There where some discussion on > how to do this, the consensus seems to be that a pubsub node @domain > with a well known node would work. A IQ based fallback was also mentioned. > > => Possible next steps: > > * specify types of payload: Articles (atom entries?) and "vcard" for the > domain (meta data like contact address, URL, description) were mentioned > as possible payloads. > > A second method for radar metadata maintenance was discussed: > domain/service ops should be able to use a HTML form at the radar site > to update the information. > > The admins could authorize themselves to the radar web interface with a > simple token sent with a <message> to the domain/service. After that, > the ops can use the radar web interface to publish announcements, > updates and other tweaks. Useful for downtimes. > > A protocol using <presence> of the x...@domain jid to update the status > of the domain/service was mentioned as a simple alternative to keep > server status flowing. > > There where some discussion about what is federation and if we can > connect to the s2s port uninvited just because you have S2S DNS records. > No clear consensus. > > Current Radar examples: > > * http://imtrends.com/ > * > http://74.125.155.132/search?q=cache:VuFw301LIFUJ:www.jabberes.org/servers/%3Fsort%3Dhas_pep%26order%3Ddesc+jabberes+list&cd=2&hl=en&ct=clnk&gl=us > > * http://coccinella.im/servers/servers.html > * http://coccinella.im/servers/servers_by_pubsub_pep.html > > > 2. Domain for the radar > > Several proposals: > > * radar.xmpp.net; > * xmpp-services.org; > * monitor.im; > * up.im; > * imradar.com / imradar.org (Ed: it seems that monitor and radar are the > same project? I don't think they are.); > * uptime.im. > > > 3. Monitoring > > A service to monitor servers uptime was also discussed. Tobias is > working on something like that. His current interface is at > http://monitor.ayena.de. > > The consensus seems to be that the monitoring should be done > distributed, and reports would be send to a collector agent that would > correlate the information. > > Some (stpeter, melo) would like to see the Server Roster XEP used for > monitoring, for example, having each server monitor all the servers in > his roster. > > Some domains where suggested to host this service: > > * yourstatus.org; > * viewstatus.org; > * whatsup.im; > * bigbrother.im; > > => Possible next actions: > > * ??; > > > 4. Robots > > robots.txt for xmpp: a version of the HTTP ad-hoc protocol for crawler > control was discussed. > > Several options for implementation - a new <feature> in disco#info. The > robots.txt file would be available with a iq-based protocol or on a well > known pubsub node on the server. the server vcard was also mentioned as > a possible place for this > > no further talk about what this robots.txt would contain. It was > suggested to use the same format as HTTP but no discussion about if that > is appropriate or workable.... > > => Possible next actions: > > * define a "robots.txt" format for XMPP use; > > > > 5. Domain admins > > The topic of which JIDs should be accepted as domain admins was present > through out the conversation. The x...@domain and ow...@domain > hard-coded addresses where noted, as was XEP-0157. > > A disco#items method for discovering admin JIDs (using a well-known node > value like 'urn:xmpp:valid-admins' for example) was also floated. Using > a well known pubsub node @domain was also presented as an alternative. > > There was no clear consensus but several people (Mickael, bear, melo) > prefered a pubsub-based approach. > > > 6. Other topics > > A brave attempt by JMcA to bring the subject of a standard server > configuration file format to ease the pain of switching servers. > > > Best regards, > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpJQaIACgkQNL8k5A2w/vxWNACeK8TMvevtL3auUBAr+2Q52cqg r0sAoIZEio0BMgTJvDtHPDGs56MQW8ke =KxNX -----END PGP SIGNATURE-----
