Use of complete GList functionality? Change to GSList?

[Derek Atkins]

Dave Peticolas <dave@krondo.com> writes:

> Ok. As long as you are doing the copy, you might consider using the
> engine API to build the 'real copy' rather than just copying the
> structure itself. That would make the RPC backend much more robust
> against implementation changes. For example, a lot of the strings in
> the structures are really handled by the engine string cache, and
> should't be directly malloc'd with either libc or glib routines.
> Having the backend so dependent on the internal structure and
> implementation of engine objects makes me very nervous.

Yea, I've kinda decided to to that on the 'receiving' end.  However,
I'd still like to be able to use the engine objects on the 'sending'
end, as much as possible.  I guess I'll just have to resign myself to
copying data back and forth.

> Backend aside, there are probably several uses of GList in the
> engine that could be converted to GSList without losing needed
> functionality.

Doing this would be nice; it would make it easier to just "send" an
engine object because the engine structure and RPC structure can be
memory-equivalent.  For example, I _think_ I can just _send_ a
QueryTerm list without any other modifications or data copying.

> dave

-derek

PS: Are there any places where a kvp_frame actually is of type
GLIST?  I'm not sure how to handle those cases, yet.
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available