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

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



> From: owner-jdev@jabber.org On Behalf Of dsmith@ai.uwf.edu
> Subject: [JDEV] Client Lib & Associated Thoughts (And Many Capital
> Letters)
> This one's gonna be long. Better make sure you have some Dew... :)

	Nah, it's morning.. Coffee..  ;-P

<Much GOOD docs snipped>

> 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);
> }

	The above already exists as the xpt struct in the common libs, as shown
below:

typedef struct xpt_struct
{
	int type;
	int status;
	char *name;
	char *value;
	jpair *attributes;
	struct xpt_struct *children;
	struct xpt_struct *next;
	struct xpt_struct *parent;
} xpt;

	All your above really does is objectasize (IS that a word?) this type of
thing.

> 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. :)

	See above, only thecommon lib current has functions in xpt.c that do what
your talking about.  Here's an idea.  We could do exactly what your talking
about, but write some C++ wrappers around the current code, hence, we have
both a C and C++ way of doing things..

> 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++?

	I am doing this current in the Windows client, using Visual C++.  My
original idea was exactly what your talking about, making a generic C++
class, in my case, stored in a DLL that could be used by any program to
'Jabberify' it easily.

	I like where your going, but I think we can use our current code base to do
this fairly easily..