[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..