Re: [Evolution-hackers] New 'eclient' branch in eds

[Milan Crha <mcrha redhat com>]

On Thu, 2011-04-28 at 15:04 -0400, Matthew Barnes wrote:
> On Thu, 2011-04-28 at 19:53 +0200, Milan Crha wrote: 
> > Only the last thing for the enum values, I would personally prefer
> > something with a prefix E_CLIENT_SOURCE_TYPE_... only to not have it
> > confusion-able with E_CLIENT_TYPE constant.
> 
> Do you mean E_TYPE_CLIENT (for getting EClientClass's GType)?

Heh, right, I meant E_TYPE_CLIENT. I should read-before-write more
often, I'm sorry.

> Regardless, I'm fine with the longer prefix if you'd prefer that.

Preferred on my side, yup.

> > By the way, the proposed merge of server side parts, it may also involve
> > merging client side bits (for E*View) and thus finally drop all the old
> > cruft. It's a benefit, I hope, even with broken backward compatibility.
> > (I would prefer to break backward compatibility personally, rather than
> > inventing special names for structs not intersect with old names.)
> 
> I haven't been following the E*View changes very closely.  What's
> considered cruft?

There was just a little problem with ECalView, which had 'client'
property, which is referring to ECal, instead of ECalClient, and I was
forced to "invent" different name for it. But after a bit of sleeping
and small thinking I might be wrong on this point too, as it should be
easy to define EBookClientView/ECalClientView and keep old
EBook/CalView-s as they are, at least their public API.

I see I did really too quick thinking on these.
	Bye,
	Milan