Difference between revisions of "User:Jwi/Application 2018"

From XMPP WIKI
Jump to navigation Jump to search
m (fix URL to (and name of) JabberCat)
(add some more notes, also some light reformatting)
Line 1: Line 1:
 +
=== Metadata ===
 +
 
; Name: Jonas Wielicki
 
; Name: Jonas Wielicki
 
; Profession: Computer Science student
 
; Profession: Computer Science student
Line 6: Line 8:
 
; Company: Cloud&Heat Technologies GmbH
 
; Company: Cloud&Heat Technologies GmbH
  
==== Background ====
+
=== Background ===
  
 
I am mainly in the realm of client development. I started actually using XMPP in about 2010, and soon began to develop "bots" which perform several tasks based on SleekXMPP. The versatility of XMPP I learnt about in that process hooked me for the protocol.
 
I am mainly in the realm of client development. I started actually using XMPP in about 2010, and soon began to develop "bots" which perform several tasks based on SleekXMPP. The versatility of XMPP I learnt about in that process hooked me for the protocol.
  
In 2014 I decided to start developing an XMPP library ([https://github.com/horazont/aioxmpp aioxmpp]) and client ([https://github.com/jabbercat/jabbercat JabberCat], very incomplete) on my own. The client is targeted for the Desktop user while the library has no specific target audience and is intended to be usable for about every client scenario. As a newcomer, I am very interested in the quality of the XEP specifications, because this is essentially the only resource developers have when writing code for XMPP entities.
+
In 2014 I decided to start developing an XMPP library ([https://github.com/horazont/aioxmpp aioxmpp]) and client ([https://github.com/jabbercat/jabbercat JabberCat], very incomplete) on my own. The client is targeted for the Desktop user while the library has no specific target audience and is intended to be usable for about every client scenario. I am very interested in the quality of the XEP specifications, because this is essentially the only resource developers have when writing code for XMPP entities.
 +
 
 +
=== General attitude ===
 +
 
 +
I think XMPP as an IM application (Jabber) currently has two main issues: On-boarding and Message Routing.
 +
 
 +
; On-boarding: Especially compared to other modern IM solutions, Jabber is inconvenient to set up (cf. [[Easy Onboarding]]). The work which is being done in the area is promising, and I like to participate in those discussions. We need to massively simplify the on-boarding process of non-Jabber users.
 +
; Message Routing: This is a big one. The routing (and archiving) rules for messaging have grown historically and are often only vaguely defined, leading to interesting (inter-)operability issues. While the idea of only vaguely defining rules in order to allow for wiggle-room for experiments is in its core not bad, the fact that Message Routing is an insanely complex problem makes vague rules frustrating to developers of both clients and servers (not to mention, their users when something goes wrong). The complexity isn’t exactly alleviated by the fact that they touch the very core of an IM solution: being able to deliver messages reliably. I think the issue deserves a proper solution which considers all modern use-cases alike—which is a very difficult problem.
  
==== Why should I vote for you? ====
+
=== Why should I vote for you? ===
  
 
This is my second term. My first term helped me to stay closer to the standards process, especially since I joined the Editor team. I helped resurrecting the xmpp.net checker (although it is still not working flawlessly).  
 
This is my second term. My first term helped me to stay closer to the standards process, especially since I joined the Editor team. I helped resurrecting the xmpp.net checker (although it is still not working flawlessly).  
  
 
I intend to continue my Editor team membership and further contribute to the editor infrasturcture, website and other pieces of the XSF. In addition to that, I intend to continue to follow the standards process and contribute; even though this is nothing for which I ''technically'' need to be a member, being integrated in the XSF structure helps motivate that.
 
I intend to continue my Editor team membership and further contribute to the editor infrasturcture, website and other pieces of the XSF. In addition to that, I intend to continue to follow the standards process and contribute; even though this is nothing for which I ''technically'' need to be a member, being integrated in the XSF structure helps motivate that.

Revision as of 14:15, 11 January 2018

Metadata

Name
Jonas Wielicki
Profession
Computer Science student
JID/Email
jonas@wielicki.name, j.wielicki@sotecware.net (both work as Email and JID)
Nicknames
jonasw (in MUCs), horazont (on GitHub and IRC)
University
Technische Universität Dresden
Company
Cloud&Heat Technologies GmbH

Background

I am mainly in the realm of client development. I started actually using XMPP in about 2010, and soon began to develop "bots" which perform several tasks based on SleekXMPP. The versatility of XMPP I learnt about in that process hooked me for the protocol.

In 2014 I decided to start developing an XMPP library (aioxmpp) and client (JabberCat, very incomplete) on my own. The client is targeted for the Desktop user while the library has no specific target audience and is intended to be usable for about every client scenario. I am very interested in the quality of the XEP specifications, because this is essentially the only resource developers have when writing code for XMPP entities.

General attitude

I think XMPP as an IM application (Jabber) currently has two main issues: On-boarding and Message Routing.

On-boarding
Especially compared to other modern IM solutions, Jabber is inconvenient to set up (cf. Easy Onboarding). The work which is being done in the area is promising, and I like to participate in those discussions. We need to massively simplify the on-boarding process of non-Jabber users.
Message Routing
This is a big one. The routing (and archiving) rules for messaging have grown historically and are often only vaguely defined, leading to interesting (inter-)operability issues. While the idea of only vaguely defining rules in order to allow for wiggle-room for experiments is in its core not bad, the fact that Message Routing is an insanely complex problem makes vague rules frustrating to developers of both clients and servers (not to mention, their users when something goes wrong). The complexity isn’t exactly alleviated by the fact that they touch the very core of an IM solution: being able to deliver messages reliably. I think the issue deserves a proper solution which considers all modern use-cases alike—which is a very difficult problem.

Why should I vote for you?

This is my second term. My first term helped me to stay closer to the standards process, especially since I joined the Editor team. I helped resurrecting the xmpp.net checker (although it is still not working flawlessly).

I intend to continue my Editor team membership and further contribute to the editor infrasturcture, website and other pieces of the XSF. In addition to that, I intend to continue to follow the standards process and contribute; even though this is nothing for which I technically need to be a member, being integrated in the XSF structure helps motivate that.