Justin Johansson wrote:
Adam Ruppe wrote:
I'm not terribly interested in it because I already wrote my own
replacement: http://arsdnet.net/dcode/dom.d
Mine is biased toward HTML, doing what I personally find useful, or
mimicing what javascript in the browser would do instead of following
the standard, but if there's anything in there that is useful to
others, you're free to take it.
Thanks Adam for replying. I'm happy to take onboard contra-views
such as yours as well. Naturally it is no point in putting in an
effort wherein there is no interest at large.
Still, I'll wait for more replies on this ng before making any
decision whether or not to commit myself to a new "D2 XML" effort.
Clearly std.xml can't stay the way it is. I'm even thinking of removing
it preemptively in wait for another implementation.
If you want to work on something you enjoy, it seems like std.xml is a
good choice. If you want to work on the top most important item,
probably networking would come ahead. We badly need http and ftp
streaming libraries. I'm thinking libcurl would be a good choice as a
backend (not interface). For D integration, it would be great to
integrate networking with std.stdio.File - e.g. creating
File("http://xyz.org";) would just connect to the thing and allow
streaming, ranges, everything. Adam Ruppe has a lower-level networking
protocol that also hooks into std.stdio.File, which would be very
important to have too.
But then it's often better to work on what you like, so don't look for a
landslide vote. Ford didn't work on a faster horse etc. Some things that
would be good to have in an xml library:
- should work with input ranges (not only strings)
- use aliases as lambdas if needed (std.xml's use of lambdas is nice,
just very slow)
- define templates for char, wchar, and dchar and then define one
working with ranges of ubyte that dispatches depending on the encoding
tag found.
Andrei
