mirror of
git://git.psyc.eu/libpsyc
synced 2024-08-15 03:19:02 +00:00
Merge branch 'master' of supraverse.net:libpsyc
This commit is contained in:
commit
c5343bd354
3 changed files with 61 additions and 20 deletions
|
@ -14,20 +14,6 @@ a more efficient XML encoding based on PSYC methods, to have
|
|||
a more accurate comparison of the actual PSYC and XML
|
||||
syntaxes, rather than the protocol structures of PSYC and XMPP.
|
||||
|
||||
== Caveats ==
|
||||
|
||||
In every case we'll compare performance of parsing and re-rendering
|
||||
these messages, but consider also that the applicative processing
|
||||
of an XML DOM tree is more complicated than just accessing
|
||||
certain elements in a JSON data structure or PSYC variable
|
||||
mapping.
|
||||
|
||||
For a speed check in real world conditions which also consider the
|
||||
complexity of processing incoming messages we should compare
|
||||
the performance of a chat client using the two protocols,
|
||||
for instance by using libpurple with XMPP and PSYC accounts.
|
||||
To this purpose we first need to integrate libpsyc into libpurple.
|
||||
|
||||
== The Benchmarks ==
|
||||
|
||||
=== A presence packet ===
|
||||
|
@ -47,7 +33,7 @@ Here's an example from paragraph 4.4.2 of RFC 6121.
|
|||
And here's the same information in a JSON rendition:
|
||||
|
||||
{{{
|
||||
... <insert jsonRender>
|
||||
["presence",{"from":"juliet@example.com/balcony","to":"benvolio@example.net"},{"show":"away"}]
|
||||
}}}
|
||||
|
||||
Here's the equivalent PSYC packet in verbose form
|
||||
|
@ -101,7 +87,8 @@ storage information. We'll again start with XML:
|
|||
In JSON this would look like this:
|
||||
|
||||
{{{
|
||||
... <insert json rendering of DOM tree?>
|
||||
["UserProfile",{"Name":"Silvio Berlusconi","JobTitle":"Premier","Country":"I","Address":
|
||||
{"Street":"Via del Colosseo, 1","PostalCode":"00100","City":"Roma"},"Page":"http://example.org"}]
|
||||
}}}
|
||||
|
||||
Here's a way to model this in PSYC:
|
||||
|
@ -138,3 +125,17 @@ JSON as payloads within PSYC for data that doesn't fit the PSYC model.
|
|||
For some reason all three formats are being used for messaging, although
|
||||
only PSYC was actually designed for that purpose.
|
||||
|
||||
== Caveats ==
|
||||
|
||||
In every case we'll compare performance of parsing and re-rendering
|
||||
these messages, but consider also that the applicative processing
|
||||
of an XML DOM tree is more complicated than just accessing
|
||||
certain elements in a JSON data structure or PSYC variable
|
||||
mapping.
|
||||
|
||||
For a speed check in real world conditions which also consider the
|
||||
complexity of processing incoming messages we should compare
|
||||
the performance of a chat client using the two protocols,
|
||||
for instance by using libpurple with XMPP and PSYC accounts.
|
||||
To this purpose we first need to integrate libpsyc into libpurple.
|
||||
|
||||
|
|
|
@ -133,17 +133,36 @@ struct ParseState
|
|||
* Params:
|
||||
* flags = Flags to be set for the parser, see ParseFlag.
|
||||
*/
|
||||
static ParseState opCall ( ubyte flags )
|
||||
static ParseState opCall ( ParseFlag flags )
|
||||
{
|
||||
ParseState inst;
|
||||
inst.flags = flags;
|
||||
|
||||
if (flags & ParseFlag.ROUTING_ONLY)
|
||||
if (flags & ParseFlag.START_AT_CONTENT)
|
||||
inst.part = Part.CONTENT;
|
||||
|
||||
return inst;
|
||||
}
|
||||
|
||||
/**
|
||||
* Change parse flags in state
|
||||
*
|
||||
* Params:
|
||||
* state = Pointer to the state struct that should be initialized.
|
||||
* flags = Flags to be set for the parser, see psycParseFlag.
|
||||
*
|
||||
* See_Also: psyc_initParseState psycParseFlag
|
||||
*/
|
||||
void setParseFlags (ParseFlag flags)
|
||||
{
|
||||
this.flags = flags;
|
||||
|
||||
if (flags & ParseFlag.START_AT_CONTENT)
|
||||
this.part = Part.CONTENT;
|
||||
else
|
||||
this.part = 0;
|
||||
}
|
||||
|
||||
/**
|
||||
* Sets a new buffer in the parser state struct with data to be parsed.
|
||||
*
|
||||
|
|
|
@ -17,8 +17,8 @@
|
|||
*
|
||||
* and the according terms are used throughout this documentation and in the
|
||||
* return codes. You should be at least
|
||||
* vaguely familiar with what the difference between "body" and "content" as
|
||||
* well as "routing variable" and "entity variable" is.
|
||||
* vaguely familiar with differences between "body" and "content" as
|
||||
* well as "routing variable" and "entity variable".
|
||||
*
|
||||
*
|
||||
* To parse a packet you first have to initialize a state:
|
||||
|
@ -268,6 +268,27 @@ void psyc_initParseState2 (psycParseState *state, uint8_t flags)
|
|||
state->part = PSYC_PART_CONTENT;
|
||||
}
|
||||
|
||||
/**
|
||||
* Change parse flags in state
|
||||
*
|
||||
* @param state Pointer to the state struct that should be initialized.
|
||||
* @param flags Flags to be set for the parser, see psycParseFlag.
|
||||
* @see psyc_initParseState
|
||||
* @see psycParseFlag
|
||||
*/
|
||||
static inline
|
||||
void psyc_setParseFlags (psycParseState *state, uint8_t flags)
|
||||
{
|
||||
state->flags = flags;
|
||||
|
||||
if (flags & PSYC_PARSE_START_AT_CONTENT)
|
||||
state->part = PSYC_PART_CONTENT;
|
||||
else
|
||||
state->part = 0;
|
||||
}
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* Sets a new buffer in the parser state struct with data to be parsed.
|
||||
*
|
||||
|
|
Loading…
Reference in a new issue