I don't use c_glib but I do follow this list. I'm replying because I've not
seen a response to you yet, and I think its good to show that
your message has not been sent into the ether.
Your changes sound solid to me, Would be really good from a usability
perspective.
You might get more users which would be good for everyone. The old function
seems like a mess compared to your proposed changes.
On Sat, Mar 23, 2013 at 1:04 AM, Evan Nemerson <e...@coeus-group.com> wrote:
> On Fri, 2013-03-22 at 21:28 +0000, Roger Meier wrote:
> > Quoting Evan Nemerson <e...@coeus-group.com>:
> >
> > > I've been working on improving the c_glib implementation with the goal
> > > of being able to use Cassandra from Vala, C, and languages supported by
> > > GObject Introspection. Unfortunately, I've come to realize that there
> > > are some issues with the c_glib implementation which can't really be
> > > resolved without backwards-incompatible API changes to both the library
> > > and the code generated by the compiler.
> > >
> > > I'm willing to do the work to make those changes happen (and help
> > > maintain the resulting API), but I don't want to write the code until I
> > > know that people are willing to break backwards compatibility, or
> create
> > > a new implementation based on GLib/GObject/GIO and deprecate c_glib.
> > >
> > > I think the easiest way to see what I'm talking about is to look at an
> > > example, so here is the function generated for executing a prepared
> > > statement in Cassandra:
> > >
> > > gboolean
> > > cassandra_cassandra_client_execute_prepared_cql_query (
> > > CassandraCassandraIf * iface,
> > > CassandraCqlResult ** _return,
> > > const gint32 itemId,
> > > const GPtrArray * values,
> > > CassandraInvalidRequestException ** ire,
> > > CassandraUnavailableException ** ue,
> > > CassandraTimedOutException ** te,
> > > CassandraSchemaDisagreementException ** sde,
> > > GError ** error);
> > >
> > > The most obvious issue is that Thrift exceptions are not GErrors, which
> > > means that after executing the function, in addition to checking error
> > > for problems, you also need to check ire, ue, te, and sde.
> > >
> > > Next, it returns a boolean instead of what the Cassandra thrift file
> > > specified (that second argument, _return, is what Cassandra wants us to
> > > return).
> > >
> > > This function should be generated as
> > >
> > > CassandraCqlResult *
> > > cassandra_cassandra_execute_prepared_cql_query (
> > > CassandraCassandra * cassandra,
> > > const gint32 itemId,
> > > const GPtrArray * values,
> > > GError ** error);
> > >
> > > You get all the same information, but it's *much* easier to access. (I
> > > know the CassandraCassandra thing is a little weird, but that's just
> > > because of a Cassandra service in a Cassandra namespace. Not much can
> > > be done about that.)
> > >
> > > There is also the issue of moving to GIO, which would provide almost
> > > free support for things like
> > >
> > > * TLS
> > > * Compression
> > > * Things other than TCP (UDP, UNIX domain sockets, in-memory
> > > buffers, etc.)
> > > * DNS-SD, on both clients and servers
>
> Sorry, server-side isn't accurate. Nothing is stopping you from
> configuring your DNS server for DNS-SD, but there is no mDNS/UPnP stuff
> in GIO.
>
> > > * Asynchronous operations
> > > * Cancellable operations
> > > * Buffered I/O
> > > * Multi-threaded servers
> > >
> > > I know that most of those things can be accomplished with the existing
> > > API (and the last two already are), but to be honest it's a bit of a
> > > pain (especially in C), and integrating tightly with GIO could make it
> > > trivial.
> > >
> > > There are also many more minor issues. You may have noticed that I
> > > changed "CassandraCassandraIf *" to "CassandraCassandra *" above.
> > > GObject properties, and implementation details, are exposed publicly as
> > > fields when they shouldn't be. Here is what a string constant looks
> > > like in the code generated by the compiler:
> > >
> > > #define CASSANDRA_VERSION g_strdup ("19.24.0")
> > >
> > > So, what do you think? Is it time to break backwards compatibility?
> >
> > We probably do not have that many c_glib users, why not?
> > GIO features look nice, the only option to keep backward compatibility
> > is the introduction of c_gio?
>
> If you're asking why we can't just change the existing code to use GIO,
> many types expose implementation details which prevent this from being a
> viable option. Others don't expose things we would want (like
> GCancellable* parameters).
>
> If you're just asking about keeping this in one library, technically we
> could add all new code to c_glib and keep the existing c_glib stuff
> around but mark it as deprecated, but there is very almost nothing in
> c_glib I would actually want to keep. Anything dealing with I/O needs
> to be replaced (transport, protocol, server, client), which is pretty
> much the entire library. So does anything which exposes any of those
> types publicly. Even the enumeration values should be replaced (they
> use "T_" as the prefix instead of something like "THRIFT_TYPE_").
>
> If the compiler gets changed to use the new stuff it would break
> existing applications. It also makes its own mistakes (I mentioned a
> few in my original message) which this would be a good opportunity to
> clean up.
>
> I don't see a lot of benefit in doing this work in c_glib instead of
> creating a new implementation. Deprecating (or removing) the entire
> library and creating a new one would be much easier for everyone, and
> result in a much cleaner API.
>
> > What do we need? c_glib users where are you?
>
> I'm CC'ing the user mailing list on this. If anyone is using c_glib,
> please speak up!
>
>
> -Evan
>
>
