You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Evan Nemerson <ev...@coeus-group.com> on 2013/03/23 00:04:23 UTC
Re: Incompatible API changes for c_glib
On Fri, 2013-03-22 at 21:28 +0000, Roger Meier wrote:
> Quoting Evan Nemerson <ev...@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
Re: Incompatible API changes for c_glib
Posted by Rory McGuire <rm...@neonova.co.za>.
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 <ev...@coeus-group.com> wrote:
> On Fri, 2013-03-22 at 21:28 +0000, Roger Meier wrote:
> > Quoting Evan Nemerson <ev...@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
>
>
Re: Incompatible API changes for c_glib
Posted by Simon South <ss...@simonsouth.com>.
On 22/03/13 07:04 PM, Evan Nemerson wrote:
> If anyone is using c_glib, please speak up!
I'm here---I'm eyeing Thrift for a project in C and have been slowly
working on finishing c_glib's server support (
https://github.com/simonsouth/thrift), learning GLib as I go.
I have no issues with the changes Evan is proposing and would be willing
to help out; just wanted to identify myself as someone else working with
this code.
--
*Simon South*
ssouth@simonsouth.com
Re: Incompatible API changes for c_glib
Posted by Rory McGuire <rm...@neonova.co.za>.
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 <ev...@coeus-group.com> wrote:
> On Fri, 2013-03-22 at 21:28 +0000, Roger Meier wrote:
> > Quoting Evan Nemerson <ev...@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
>
>