[Standards] Initial thoughts on Raft over XMPP

Peter Membrey peter at membrey.hk
Tue Jul 21 09:53:18 UTC 2015


Hi guys,

Thanks for the encouragement and feedback!

I'm working on the ProtoXEP now and I think it's coming along quite nicely. I hope to be able to submit it soon.

I could use some guidance on how to best approach describing this protocol. The challenge is that I want to describe a transport layer for Raft, but I don't actually want to end up trying to describe Raft itself. For example, when I have an element with a number of attributes, should I be defining and explaining those attributes? Should I be explaining different conversations that two "Raft nodes" might under different (Raft related) circumstances, even though the message structure from XMPP's point of view is the same? 

I guess what I'm asking is, where should I draw the line between explaining what messages are needed in XMPP to support Raft and Raft itself...

Thanks in advance!

Kind Regards,

Peter Membrey


----- Original Message -----
From: "Matthew A. Miller" <linuxwolf at outer-planes.net>
To: "XMPP Standards" <standards at xmpp.org>
Sent: Tuesday, 21 July, 2015 01:17:17
Subject: Re: [Standards] Initial thoughts on Raft over XMPP

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On 7/20/15 5:39 PM, Matthew Wild wrote:
> Hi Peter,
> 
> On 20 July 2015 at 10:11, Peter Membrey <peter at membrey.hk> wrote:
>> Hi guys,
>> 
>> As the subject suggests, I'm really interested in using the Raft
>> consensus protocol over XMPP. I'll give you some background on
>> the project I'm working on, some info on Raft and will then try
>> to explain why I think XMPP is a great choice for transporting
>> the raft data. It's the first time I've considered working on an
>> XEP, so any constructive or critical feedback will truly be
>> welcome! Also, thanks in advance for taking the time to read
>> through all this.
> 
>> I am already working on a prototype to let me do this using
>> custom <message/> stanzas. It would be easy enough to do this as
>> 'chat' and place the payload in <body/>, but because the data
>> fits structured XML so nicely, it just seemed plain wrong to
>> overload 'chat'.
>> 
>> So, as I'm probably going to have to do this work anyway, I
>> wanted to get in touch with the community and see whether or not
>> it thinks this would be a suitable case for an XEP. To be clear,
>> I'm not suggesting we implement Raft itself in XMPP, but merely
>> define a mechanism for transporting Raft messages within a
>> cluster. I'm very happy to do the leg work and I'll certainly
>> take on board all feedback that I get. If the overall vibe is
>> positive, I'll start putting together a proto-XEP for submission
>> to the XEP Editor.
> 
> This sounds great, definitely something I'd be interested in seeing
> a XEP for :)
> 
> I would omit the message type (it defaults to 'normal') and just
> put your XML inside the message instead of a <body/>. Unless you
> have something transactional (request/response), in which case use
> an <iq/>. It should be pretty straightforward, as you say.
> 
> Finally, if this is your first XEP, some handy links:
> 
> - https://xmpp.org/extensions/xep-0134.html -
> https://xmpp.org/extensions/xep-0143.html
> 

Just a note regarding XEP-0143.  It is now possible to submit
proposals as a github Pull Request; the repository is at <
https://github.com/xsf/xeps.git >.  It's not instantaneous (the XEP
Editors are not paid to do this job, after all), but we try to be
quick and responsive.


Look forward to the protoXEP!

- -- 
- - m&m

Matthew A. Miller
< http://goo.gl/LK55L >
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJVrS0dAAoJEDWi+S0W7cO1V10IAKV9gPkBrNXyq+qO5vb9fExf
qDYd/gpLsYgQCSzxn21IJi5WdgzkallBn2fbmZPK58j7Oxf1IAkF8QPFSeLwwhar
y3TJ+ToQPwroyhRggKO8UjJVomf9WmXiSx/eK52cwh4uz2u0j21F+MJGV2mUUXAS
uQRKsZUiQODGprMgRr5qiP2yCaCHS+S1vZyfIP486y5iDNdmDarJEvQ2zfvRcWLW
zod/3Aj5vptyx0T5b/KFuvJdRDZqBZHoPe+/r4pVXGj2+9xinV+zVLU4FD+RcP+M
c2jEpmgz43iNj6kWtREWzE+WbJ76lOKgmF5UOETm65djhVCHajlP3eqD9qRXofo=
=ngYC
-----END PGP SIGNATURE-----



More information about the Standards mailing list