68
edits
(New page: This space temporarily left blank.) |
(Submitted) |
||
Line 1: | Line 1: | ||
My name is [http://matthewwild.co.uk/ Matthew Wild] (and sometimes 'MattJ'), and I am located in the United Kingdom. I have been an XSF member since January 2008. | |||
== Me and XMPP == | |||
My main work at the moment, since launching the project in 2008, is in leading the development of [http://prosody.im/ Prosody], a lightweight XMPP server. For details of my other XMPP-related work, feel free to browse my XSF [[Matthew_Wild_January_2010|membership applications]]. | |||
== XMPP Council == | |||
I was elected a council member for 2009-2010, and am standing again with the aim of continuing the work we have been doing. | |||
In the coming term I personally will be focusing on improving specifications for message archiving, stream reliability/resumption (XEP-0198), invisibility and an "better" component protocol (~XEP-0225). I would also mention the various spam/spim specifications here, but I believe they need implementations now, not more specifications. Therefore with my server developer's hat on I'll be implementing those whether I'm elected to council or not :) | |||
Very much in line with my software development principles, I favour [http://xmpp.org/extensions/ XEPs] that: | |||
* Are as small (limited in scope) and as simple as possible, but obviously no simpler | |||
* Allow for fast and efficient implementations; for servers especially, but also clients | |||
* Don't needlessly duplicate existing protocols in use | |||
* Have working existing or proof-of-concept implementations | |||
I won't specifically mention criteria related to the actual document's writing style itself, [http://stpeter.im/ Peter Saint-Andre] already does an excellent job of writing and tidying XEPs during the standards process, and ensures they contain plenty of examples and cross-references. The XMPP specifications are unrivalled in that respect :-) | |||
If you agree with the above then yay, you found a reason to vote for me! |