[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[JDEV] Client Lib & Associated Thoughts (And Many Capital Letters)



Greetings...

This one's gonna be long. Better make sure you have some Dew... :)

By nature, XML is a heirarchial language. Basically, you can take any
well-formed XML document and parse it into a N-ary tree (tree with n
children per parent). This is a very powerful concept and I think we can
put it into good use. 

Let's define some specific terminology (for debate):

Tag: an XML tag (e.g. <d> or </d> or <d/>

Conversation: the exchange of XML tags between two processes (whether
they be local or remote). 

Session (a.k.a root tag): a set of tags (in this case,
<jabber></jabber>) that signify the beginning and ending of a
jabber client/server conversation. 

Packet: a set of *specific* tags (and all data contained within) which
represent a complete thought in a conversation. In the current protocol,
<message></message> <roster></roster> <login></login> are all examples
of a packet. Each packet may contain many sub-tags and datums.

Attribute: a name/value pair stored within an opening tag. Each tag
may have multiple attributes. 

Datum: a raw value stored between two tags. For instance,
in the packet "<d>HELLO!</d>" the string "HELLO!" is the datum. Each
tag may contain multiple datums, each seperated by a set of sub-tags.
For instance, in the packet "<d>HELLO!<sd>Greetings</sd>QUICK!</d>",
the "d" tag has multiple datums "HELLO!" and "QUICK!". Multiple datums
are merged into a single unbroken string (still thinking about this
idea...)

At this point, you should be warned that I've worked primarily with
object-oriented languages and will express my structure in a loose C++
grammar...

With these definitions in mind, we can specify a set concrete data
structures to represent a parsed XML session. We (could have) the
following objects/data structures:


class tag_t
{
  // Variables
  char* name;

  attribset_t* attribs;
  tagset_t*    tags;

  char*  datum;

  // Operations
  char* getAttribValue(char* AttribName);
  char* getDatum();
  tag_t* getTag(char* TagName);

  bool hasAttrib(char* AttribName);
  bool hasTag(char* TagName);
}

class attrib_t
{
  // Variables
  char* name;
  char* value;
}

class attribset_t
{
  // Maintains some hashtable of attrib_t pointers, hashed
  // by name for quick lookup

  // Operations
  bool  hasAttrib(char* AttribName);
  char* getAttribValue(char* AttribName);
  attrib_t* getAttrib(char* AttribName);
}

Basically these objects provide a way to represent a complete XML
document, along with navigation of the sub-tags. This is really
critical to the client libs. This way, people who write clients don't
have to even worry about linking with expat or parsing XML. When a
packet arrives from the server, it's parsed into a tag_t and returned
to the client with no thinking on the client side. It would probably be
best to use this at the common lib level, since the entire project
would benefit from such a structure. :)

If you are lost, say so and I'll post an example of how these objects
would interact. :)

So, that's the first of my thoughts on the client-lib. I realize that
the project is C. May I politely inquire as to the possiblities of
using c++? 

More later. :)

D.