thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evan Nemerson <e...@coeus-group.com>
Subject Re: Incompatible API changes for c_glib
Date Fri, 22 Mar 2013 23:04:23 GMT
On Fri, 2013-03-22 at 21:28 +0000, Roger Meier wrote:
> Quoting Evan Nemerson <evan@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


Mime
View raw message