Hi,
The xsd_namespace directive on the other hand does exactly what I need it
to do... so I was wondering if it is feasible to "un-deprecate" that
feature. It seems like this would not be a huge problem or terribly
detrimental to the project, but I don't know the background on the
decision to deprecate that feature so I won't make assumptions.
You mean that message?
'xsd_namespace' is deprecated. Use 'namespace xsd' instead
There are a number of namespaces like XXX_namespace that fall into the same
category. Those have been deprecated long ago, in favor of the more
consistent and more easily expandable naming scheme that we have today. What
does 'xsd_namespace' do that 'xsd' cannot?
Have fun,
JensG
-----Ursprüngliche Nachricht-----
From: BCG
Sent: Tuesday, November 10, 2015 5:04 AM
To: dev@thrift.apache.org
Subject: Re: Working on a Thrift protocol on top of XML
On 11/05/2015 04:28 PM, Jens Geyer wrote:
Hi Ben,
the following is more or less my personal perspective on that matter, so
please take it with a grain of salt.
Hi Jens
I appreciate your perspective, and I thank you for taking the time to
write a thoughtful response
After reading the initial words I had a hard time thinking about a use
case. But what made me thinking was the "foot in the door" by providing
(basically) Thrift over SOAP. Interestingly, and despite it's bloaty
overhead, despite the existing alternatives around and despite lots of
(in some cases hopelessly) buggy SOAP implementations on the market, SOAP
is still a major cornerstone in the industry. An astonishing number of
people still thinks of SOAP as the ultimative, one and only, lingua franca
to connect various systems, even today, in 2015.
The approach you sketched could indeed be an entry point into that
ecosystem, by providing the tools to seamlessly replace SOAP, or even
other implementations, by avoiding the big switch to another technology.
It takes the pressure out of that technology move by allowing small,
step-by-step conversions, and that could indeed make the difference.
The only thing where I'm not so sure about is the question, whether this
should really become a part of the core Thrift libraries, or whether it is
more like a contribution, or derived project. Frankly I tend more to the
latter, because of two reasons:
a) it clearly is an addition to Thrift Core
b) supporting SOAP is not really alignable with the project goals, as
written on http://thrift.apache.org/about
I can definitely see your point ... indeed most aspects of my project
can be implemented outside of the Thrift core, especially given the
goals you cited. Perhaps the main reason that I brought it to the dev
list was that part of my task has been to design a new protocol format,
which has some involves some considerations just programming. As I said
though, I definitely see your point.
At the moment there is 1 thing I've encountered that could be addressed
in the compiler and would be a benefit to me. Right now, if you use the
"xsd_namespace" directive in an IDL file, the compiler issues a warning
that this is deprecated and will be removed in a future version, and to
use "namespace xsd" instead. This is a less than useful suggestion in my
use case however, as it does not allow for some characters typically
found in an XML namespace. The xsd_namespace directive on the other
hand does exactly what I need it to do... so I was wondering if it is
feasible to "un-deprecate" that feature. It seems like this would not
be a huge problem or terribly detrimental to the project, but I don't
know the background on the decision to deprecate that feature so I won't
make assumptions. If it is not possible/desirable to leave support of
that directive in IDL, if you can think of a reasonable alternative that
I could use, that would be helpful.
Apache Thrift is a software project spanning a variety of
programming languages and use cases. Our goal is to make reliable,
performant communication and data serialization across languages as
efficient and seamless as possible. [...]
Apache Thrift aims to embody the following values:
* Simplicity Thrift code is simple and approachable, free of
unnecessary dependencies.
* Transparency Thrift conforms to the most common idioms in
all languages.
* Consistency Niche, language-specific features belong in
extensions, not the core library.
* Performance Strive for performance first, elegance second.
So while I see the value, at this time I don't think we should make it
part of the core library. Theoretically, it could find a place under
/contrib, with some clear documentation about the intended purpose, but
then it will probably become a somewhat less maintained part of the source
tree (well, we have to face the facts here) - and I doubt if that will
really serve your project. From my perspective, as a side-project or
derived project it makes the most sense. Maybe we can promote it somehow
on the Thrift web site, under a "derived projects" section or the like.
That would be great! I think that is a good idea in general... having a
section like that would certainly be helpful to the community around
Thrift I'm sure.
Thank you again for your feedback.
$0,02
Have fun,
JensG
-----Ursprüngliche Nachricht----- From: BCG
Sent: Thursday, November 5, 2015 9:44 PM
To: dev@thrift.apache.org
Subject: Working on a Thrift protocol on top of XML
Greetings Thrift devs
I've been working on a Thrift protocol implementation on top of XML, and
I would like to get some feedback from you if you have a chance to take
a look at my work.
I know mixing Thrift and XML is probably anathema to some but I see some
important benefits for interoperability, especially in the "enterprise"
world.
In short, I've designed an XML format that can be consumed by a
streaming XML parser in a manner consistent with Thrift semantics, and a
reference implementation in Java is completed (linked below).
I've also started work on some XSL transformations to convert from the
streaming format to more "standard" XML formats like SOAP web services
etc. There is of course performance overhead with this but I think it
might provide a good migration path to the "native" thrift formats in
many cases - "a foot in the door" if you will. Frankly I'm not an XSL
expert but in my thinking, if you all like this protocol, doing these
transformations with XSL should make the amount of effort to implement
in languages smaller (languages would only need to implement the
streaming protocol, in other words).
My intention is to contribute the results of this effort to the Thrift
project if you all like it and find it useful. Before doing that
however I would like to know if there are ways in which this format
could be improved, or if I am barking up the wrong tree. If you are
able to review my work, your time in doing so as well as your feedback
is definitely appreciated.
Please find my project here and a more detailed write-up here:
https://github.com/bgould/thrift-xml-protocol
Thank you
Ben
