A
aaronwmail-usenet
ANN: xsdbXML release with C#/.NET port
Part I: Announcement
====================
There is a new release of xsdbXML which provides
bugfixes to the Python implementation and also
provides a completely separate implementation in C#/.NET.
The xsdb framework provides a flexible and well defined
infrastructure to allow tabular data to be published,
retrieved, and combined over the Internet.
Read more and download at
http://xsdb.sourceforge.net
Part II: Discussion
===================
The C# implementation is primarily a transliteration
of the Python implementation. I hope to also do a java
transliteration of the C# code. Some brief observations:
- Development:
Using python for the first implementation was the
right way to go because it made it easier to backtrack
and refactor the implementation. If I had tried this
in C# backtracking would have been much more painful.
Testing Python code, especially during development, is also
much easier in part because you can write
{"a": [1,2,3], "b": MyClass("argument")}
in a few keystrokes whereas a C# analogue runs to many
lines.
Interestingly, however, the C# port exposed several
nasty bugs in untested code paths of the python
implementation (incorrect calling sequences) because of C#
static typing, even before the C# code was running or
even compiling.
For the most part the transliteration was
straightforward, except where the python implementation
leans on the python expression parser (the parser had
to be "hand rolled" in C#).
- Libraries:
The python http services are more "bare bones" than the
..NET libraries and this is a *GOOD* *THING* (tm). The
..NET libraries seem to do all kinds of nice things under
the surface where I can't influence their behavior (even
in principal because of the type system information hiding).
The python implementation pretty much allows me to
modify any part of the implementation, and the default does
as little as possible. My reservations about the C# http
services didn't actually cause problems in this case, but
it made me nervous.
On the other hand it's nice in C# to not have to guess about
which XML library to use. As any python programmer can
attest it is not fun trying to decide which of several
implementations is the best and will stay alive, etcetera.
I just arbitrarily chose the one I knew already, but I
really should switch to something else, dunno what.
In C# there is only one choice.
- Environment
What can I say. VS/.NET is really nice and there is
nothing close in Python AFAIK.
- Conclusion
Don't have any. I'm just making comments
.
Thanks for your attention -- Aaron Watters
===
% if I had a ( for every $ bush spent how many ('s would I have?
too many ('s
Part I: Announcement
====================
There is a new release of xsdbXML which provides
bugfixes to the Python implementation and also
provides a completely separate implementation in C#/.NET.
The xsdb framework provides a flexible and well defined
infrastructure to allow tabular data to be published,
retrieved, and combined over the Internet.
Read more and download at
http://xsdb.sourceforge.net
Part II: Discussion
===================
The C# implementation is primarily a transliteration
of the Python implementation. I hope to also do a java
transliteration of the C# code. Some brief observations:
- Development:
Using python for the first implementation was the
right way to go because it made it easier to backtrack
and refactor the implementation. If I had tried this
in C# backtracking would have been much more painful.
Testing Python code, especially during development, is also
much easier in part because you can write
{"a": [1,2,3], "b": MyClass("argument")}
in a few keystrokes whereas a C# analogue runs to many
lines.
Interestingly, however, the C# port exposed several
nasty bugs in untested code paths of the python
implementation (incorrect calling sequences) because of C#
static typing, even before the C# code was running or
even compiling.
For the most part the transliteration was
straightforward, except where the python implementation
leans on the python expression parser (the parser had
to be "hand rolled" in C#).
- Libraries:
The python http services are more "bare bones" than the
..NET libraries and this is a *GOOD* *THING* (tm). The
..NET libraries seem to do all kinds of nice things under
the surface where I can't influence their behavior (even
in principal because of the type system information hiding).
The python implementation pretty much allows me to
modify any part of the implementation, and the default does
as little as possible. My reservations about the C# http
services didn't actually cause problems in this case, but
it made me nervous.
On the other hand it's nice in C# to not have to guess about
which XML library to use. As any python programmer can
attest it is not fun trying to decide which of several
implementations is the best and will stay alive, etcetera.
I just arbitrarily chose the one I knew already, but I
really should switch to something else, dunno what.
In C# there is only one choice.
- Environment
What can I say. VS/.NET is really nice and there is
nothing close in Python AFAIK.
- Conclusion
Don't have any. I'm just making comments
.Thanks for your attention -- Aaron Watters
===
% if I had a ( for every $ bush spent how many ('s would I have?
too many ('s