GObjectification of protocols

[Gary Kramlich]

Just a few notes from me, and sorry for my late reply I just got back from
vacation tonight :)

Having smaller interfaces does in fact make things much cleaner and easier.
 The interface type would have the "dispatcher" methods that would do a
null pointer check before calling them.  For example, say you broke out the
file transfer stuff to an interface.  You would have a method like
purple_file_transfer_cancel().  That would do the typical GObject method
override dispatch function of getting the class from the object, checking
if the pointer is null and if not calling it and possibly returning a
value.  Therefore, all of the other purple/pidgin code only needs to worry
about return values.

Also, using one interface for everything in a prpl doesn't solve the
problem of padding/structure size;  All it does is move it.  You'll still
need to pad it with something crazy like 12 members, just to be safe.
 Using small interfaces plus something like 8 padding members not only
makes sense (to me), but also makes it much easier to break up a prpl which
is how most of the core is done now already.  However, I can't speak to 3rd
party prpls, so maybe Eion can chime in.  But doesn't it atleast sound
easier to define everything in tiny blocks rather than trying to keep track
of which struct member you're working on in a 30+ member struct (assuming
you're not using named initializers)?

As for padding, yes always pad, at least 4 entries, if there's room for
something to grow big then sure bump it up.  But by breaking the prpls to
use interfaces, you no longer need to use the prpl's class struct and thus
need less padding.  For example, when we implemented whiteboards we cheated
and used a PurpleWhiteBoardOps "class" to only use 1 item in the PrplInfo
struct.  This is essentially the same thing as adding an interface, just
we're maintaining EVERYTHING rather than letting GObject maintain the
infrastructure.

Thanks,

--
Gary Kramlich <grim at reaperworld.com>


On Mon, Aug 19, 2013 at 5:43 PM, John Bailey <rekkanoryo at rekkanoryo.org>wrote:

> On 08/19/2013 12:54 PM, Tomasz Wasilczyk wrote:
> > 18 sie 2013 21:53, "Ankit Vani" <a at nevitus.org <mailto:a at nevitus.org>>
> napisał(a):
> >> This makes using smaller interfaces for convinience not necessary, but
> it may
> >> still be appealing if we want PurpleProtocolInterface to not be so huge.
> >
> > I like the idea of small interfaces. But you should pick carefully, which
> > methods should stay in main class.
>
> In general I agree with the several smaller interfaces idea.  This could
> be an
> interesting debate, though.  For example, an argument could be made to
> have the
> file transfer related bits split off as a smaller interface, since not all
> protocols support file transfer (Facebook XMPP, for example).  Note that
> I'm not
> making this suggestion, just pointing out a possibility.
>
> > Also, I think there should still be some padding bytes, in case of any
> > unexpected upgrades, that should stay in the main class.
>
> I agree entirely.
>
> John
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>



-- 
Thanks,

--
Gary Kramlich <grim at reaperworld.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20130821/7d67e94d/attachment-0001.html>