Colin Marquardt: Reverted edits by QpnQ52 (Talk); changed back to last version by DavidYip

2007-04-20T15:47:42Z

Reverted edits by QpnQ52 (Talk); changed back to last version by DavidYip

← Older revision		Revision as of 15:47, 20 April 2007
Line 8:		Line 8:
	It does not attempt to correct for lost messages (and therefore can lose objects or attribute changes very easily) or check for message integrity. Adding these features on is possible but messy.		It does not attempt to correct for lost messages (and therefore can lose objects or attribute changes very easily) or check for message integrity. Adding these features on is possible but messy.

	* The Loudmouth library is good for establishing connections and basic Jabber communication, but can be rather painful to use when dealing with other types of XMPP messages, especially of the type that are found in the Jabber MUC protocol (http://www.jabber.org/jeps/jep-0045.html). Loudmouth operates on a node-by-node basis, and this can get messy. Additionally, it's a C library with no C bindings that I know of. (Feel free to correct me if I'm wrong about this.) What I'd like to do is use a system that can make use of the Jabber MUC XML schemas to extract all the data from XMPP messages and work from there. (See http://www.jabber.org/jeps/jep-0045.html#schemas for the XML schemas.)		* The Loudmouth library is good for establishing connections and basic Jabber communication, but can be rather painful to use when dealing with other types of XMPP messages, especially of the type that are found in the Jabber MUC protocol (http://www.jabber.org/jeps/jep-0045.html). Loudmouth operates on a node-by-node basis, and this can get messy. Additionally, it's a C library with no C++ bindings that I know of. (Feel free to correct me if I'm wrong about this.) What I'd like to do is use a system that can make use of the Jabber MUC XML schemas to extract all the data from XMPP messages and work from there. (See http://www.jabber.org/jeps/jep-0045.html#schemas for the XML schemas.)

	* I inherited this codebase, and although I have the design documents, I don't have the original designers and coders to talk to. Although I have a pretty good idea of what each module does, I still find myself wondering about some pieces of the design. Additionally, the Inkboard codebase was written in C (both lingustically and stylistically). I have converted most parts to C (lingustically and stylistically), but it's still something of an ill-fiting mishmash.		* I inherited this codebase, and although I have the design documents, I don't have the original designers and coders to talk to. Although I have a pretty good idea of what each module does, I still find myself wondering about some pieces of the design. Additionally, the Inkboard codebase was written in C (both lingustically and stylistically). I have converted most parts to C++ (lingustically and stylistically), but it's still something of an ill-fiting mishmash.

	These issues make me think that it may be best to engage in a substantial redesign of the Inkboard protocol and codebase. I think that the current Inkboard class organization is okay ([[InkboardArchitecture]], coming soon) but it could really use some cleaning.		These issues make me think that it may be best to engage in a substantial redesign of the Inkboard protocol and codebase. I think that the current Inkboard class organization is okay ([[InkboardArchitecture]], coming soon) but it could really use some cleaning.

	When I stabilize Inkboard 1.0 and get it integrated into Inkscape CVS, I'll begin to write up my ideas for Inkboard 2.0 on this page. Contributions of all sorts, of course, are encouraged and greatly appreciated.		When I stabilize Inkboard 1.0 and get it integrated into Inkscape CVS, I'll begin to write up my ideas for Inkboard 2.0 on this page. Contributions of all sorts, of course, are encouraged and greatly appreciated.

QpnQ52 at 17:19, 11 April 2007

2007-04-11T17:19:27Z

New page

"Inkboard 2.0" may be something of an exaggerated descriptor, but I hope that it gets the point across.

The current Inkboard protocol and code (which I will refer to as "Inkboard 1.0" for the sake of flow) works well for one-to-one collaboration and can be extended to chatroom conferences, but after quite a bit of work on the latter I've found a few issues:

* The protocol does not seem to handle abnormal cases very well. I've only found a couple of cases where it is capable of handling errors:
** Out-of-order message receipt (i.e. it detects a situation in which sequence numbers in the message queue are not monotonically increasing)
** Excessive desynchronization (solution: drop the user)
It does not attempt to correct for lost messages (and therefore can lose objects or attribute changes very easily) or check for message integrity. Adding these features on is possible but messy.

* The Loudmouth library is good for establishing connections and basic Jabber communication, but can be rather painful to use when dealing with other types of XMPP messages, especially of the type that are found in the Jabber MUC protocol (http://www.jabber.org/jeps/jep-0045.html). Loudmouth operates on a node-by-node basis, and this can get messy. Additionally, it's a C library with no C bindings that I know of. (Feel free to correct me if I'm wrong about this.) What I'd like to do is use a system that can make use of the Jabber MUC XML schemas to extract all the data from XMPP messages and work from there. (See http://www.jabber.org/jeps/jep-0045.html#schemas for the XML schemas.)

* I inherited this codebase, and although I have the design documents, I don't have the original designers and coders to talk to. Although I have a pretty good idea of what each module does, I still find myself wondering about some pieces of the design. Additionally, the Inkboard codebase was written in C (both lingustically and stylistically). I have converted most parts to C (lingustically and stylistically), but it's still something of an ill-fiting mishmash.

These issues make me think that it may be best to engage in a substantial redesign of the Inkboard protocol and codebase. I think that the current Inkboard class organization is okay ([[InkboardArchitecture]], coming soon) but it could really use some cleaning.

When I stabilize Inkboard 1.0 and get it integrated into Inkscape CVS, I'll begin to write up my ideas for Inkboard 2.0 on this page. Contributions of all sorts, of course, are encouraged and greatly appreciated.

Inkboard2.0 - Revision history

Colin Marquardt: Reverted edits by QpnQ52 (Talk); changed back to last version by DavidYip

QpnQ52 at 17:19, 11 April 2007