Status of std.xml (D2/Phobos)

[Andrei Alexandrescu]

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