moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

XML fix /psa

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3424 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Unknown User 2009-09-14 19:30:58 +00:00
parent 3e94c38d3f
commit 9c5a86b514
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0113.xml
View File

@ -184,7 +184,7 @@
<p>One issue that will hinder all whiteboard protocol implementations is the karma problem. At least jabberd uses karma to make sure that a client does not send to much data to the server. This should help against denial-of-service attacks. When you use up all your karma, the server stops handling your messages for a while. This is a problem for whiteboards because it is much easier to send a lot of drawing data, than to send a lot of textual data. Usually combining paths, that is, sending paths when the user clicks on a send button instead of on mouse up, reduces data size because it reduces the overhead of the message element. Using the relative lineto command ('l') instead of the absolute lineto ('L') command will also reduce message size, because usually relative coordinates will only use one or two digits whereas absolute coordinates will typically use three. Finally implementations can reduce message size by not recording every mouse move event, e.g. by dropping mouse events whose locations would be accurately interpolated.</p> <p>One issue that will hinder all whiteboard protocol implementations is the karma problem. At least jabberd uses karma to make sure that a client does not send to much data to the server. This should help against denial-of-service attacks. When you use up all your karma, the server stops handling your messages for a while. This is a problem for whiteboards because it is much easier to send a lot of drawing data, than to send a lot of textual data. Usually combining paths, that is, sending paths when the user clicks on a send button instead of on mouse up, reduces data size because it reduces the overhead of the message element. Using the relative lineto command ('l') instead of the absolute lineto ('L') command will also reduce message size, because usually relative coordinates will only use one or two digits whereas absolute coordinates will typically use three. Finally implementations can reduce message size by not recording every mouse move event, e.g. by dropping mouse events whose locations would be accurately interpolated.</p>
</section2> </section2>
<section2 topic='Text'> <section2 topic='Text'>
<p>The protocol does not provide explicit support for drawing text. The reason for this is that explicit support, eg. in the form of the SVG text element <note>Text - SVG 1.0 <link url="http://www.w3.org/TR/SVG/text.html">http://www.w3.org/TR/SVG/text.html</link></note>, would break the second and third requirements above. However a client can still provide text support by representing characters as paths, eg. by using a Hershey font.</note></p> <p>The protocol does not provide explicit support for drawing text. The reason for this is that explicit support, eg. in the form of the SVG text element <note>Text - SVG 1.0 <link url="http://www.w3.org/TR/SVG/text.html">http://www.w3.org/TR/SVG/text.html</link></note>, would break the second and third requirements above. However a client can still provide text support by representing characters as paths, eg. by using a Hershey font.</p>
<p>The code snippet below shows the lines along which this could be done:</p> <p>The code snippet below shows the lines along which this could be done:</p>
<example caption='Coding the letter A into a path'><![CDATA[ <example caption='Coding the letter A into a path'><![CDATA[
// generating the path <path d='M14 6l-8,21M14 6l8,21M9 20l10,0'/> from the letter 'A' // generating the path <path d='M14 6l-8,21M14 6l8,21M9 20l10,0'/> from the letter 'A'