As for XML module, we have this shiny candy:

http://opticron.no-ip.org/svn/branches/libdxml2/xml.d

From what author says it is semi phobos ready.
Already supports up to BidirectionalRanges.

Author got a bit tired of fighting ranges, so if somebody could help, probably we could get it into phobos quite quick.

As a side note, I have used it in several projects already, and I am really happy with this (libdjson is also worth a note: http://opticron.no-ip.org/svn/branches/libdjson/json.d)

Regards

On 2/15/13 11:14 AM, Jacob Carlborg wrote:
> On 2013-02-15 15:28, Steven Schveighoffer wrote:
>
>> That is an overstatement. I'm pretty sure people are interested in
>> having serialization in Phobos.
>
> It's been in the review queue for over two years. I've pushed for it a
> couple of times to get it reviewed but got no answers. I've basically
> given up now.

Here's what I think - in order to add things to Phobos and generally the standard distribution you must revamp your entire attitude.

I have a lot of sympathy because years ago I was in the exact position. I'd written the Loki library for C++ that included many components deserving inclusion in C++'s standard library. As a first step I asked for Loki to be included in Boost. The attempt was met with interest but it soon became obvious that I'd need to go through a difficult review and make quite extensive adaptations and changes to the library in order to be considered. My attitude was "take it or leave it" and that just didn't work (and in retrospect, for the better).

Part of the proposal was a policy-based smart pointer that was superior in every way I could think of to other candidates. Yet the proposers of those candidates were willing to go through the hard work of improving and streamlining their proposals, to the point they got into Boost and ultimately into the standard. With time the relative deficiencies of that proposal was reduced by adding more kinds of smart pointers, so in the end it all got where it is today. In contrast, I was busy with my Ph.D. research so I didn't have the time to file away all rough edges.

That was a good lesson to learn. Applied to the situation of today, to get anything into the D programming language requires determination, humility, and willingness to take criticism and convert it positively. I think assuming that Orbit is a great finalized design that others fail to appreciate is definitely the wrong starting point. The right starting point is asking for feedback, integrate it, and ask again, all in a loop.


Andrei

On Friday, 15 February 2013 at 14:14:43 UTC, Jacob Carlborg wrote:
> On 2013-02-15 14:53, Andrei Alexandrescu wrote:
>
>> We have personally contacted the author of curl and the maintainer of
>> libz to make sure there are no licensing or other issues with bundling
>> their code with the D distribution.
>
> There's no issue in bundling BSD licensed code. That's the whole idea of open and free software. To be able to freely distribute the code.

To add to this. BSD requires the license be distributed with Binary forms, Boost explicitly does not. That is their real difference.

This is something Walter wants to avoid with the standard library (I agree) but for utility programs it is unimportant since they can be used to build the binary and since they are not distributed with the created binary there is no need to distribute the BSD license.

So the discussion for the library Orbit uses should remain related on how much trouble there will be from having an official program use a library not part of d-programming-language/tools and friends.

On Friday, 15 February 2013 at 16:54:06 UTC, Simen Kjaeraas wrote:
> It's not listed in the review queue on the wiki:
>
> http://wiki.dlang.org/Review_Queue

Well than that isn't complete:

http://www.prowiki.org/wiki4d/wiki.cgi?ReviewQueue

On Friday, February 15, 2013 08:46:39 Andrei Alexandrescu wrote:
> Sure, as long as the admittance barrier stays high. One the worst things we've done was to allow contributions to the standard library without due review.

We have enough problems when we _do_ review things thoroughly. But added the review process was one of the best things that we've done. The code quality of submissions has improved considerably. And as the writer of the first module to go through the process (std.datetime), I can testify that it helped considerably in improving it. What we ended up with was actually quite different in a number of places from what was originally implemented, and it's far better for it.

The main thing that we may want to do differently in the future is to give new modules more of an incubation period where they're distributed with Phobos but are clearly marked as still being experimental so that we can make further modifications when they start actually getting used and issues crop up. And then after a few releases, we actually start treat its API as being as close to frozen as the rest of Phobos is. But regardless, we certainly don't want to lower the bar of admission. It's what's going to ensure that Phobos is a solid standard library.

- Jonathan M Davis

On 2013-02-15 17:38, Steven Schveighoffer wrote:

> This is the last "push" I can find from you:
>
> http://forum.dlang.org/post/jcmp6s$1cs5$1@digitalmars.com
>
> Doesn't sound ready.

That was 1+ year ago. It does build with DMD 2.061 and all tests pass.

> On trello, it's still listed as "in development."  I'm pretty sure
> nobody is using that, though.

I have no idea of what's on trello. I take no responsible for who put it there.

> If you have given up, I suppose there is no point in asking if you are
> still interested in having it reviewed, but it sure doesn't sound like
> it was ever "in" the review queue.  Quite possible I missed the message
> that says "OK, can we review orange? it is ready".

If there are actually people interested in reviewing I'm all for it but I have not seen any trace of that.

-- 
/Jacob Carlborg

On 2013-02-15 17:54, Simen Kjaeraas wrote:

> It's not listed in the review queue on the wiki:
>
> http://wiki.dlang.org/Review_Queue

It's been on the old wiki for quite some time:

http://prowiki.org/wiki4d/wiki.cgi?ReviewQueue

> Well, it is now, since I added it. Also relabeled it std.serialization,
> because I think std.orange (or just orange) might be a tad too opaque
> for newcomers. Mayhap I shouldn't have added it (there should be a wiki
> page about this), but done is done. If I can figure out what's required
> to be a review manager, I guess I could shoulder that burden too.


-- 
/Jacob Carlborg

On 2013-02-15 18:20, Andrei Alexandrescu wrote:

> Here's what I think - in order to add things to Phobos and generally the
> standard distribution you must revamp your entire attitude.

Sure I may not have had the best attitude in this discussion. But that has nothing to do with me trying to get Orange into Phobos several years ago.

> I have a lot of sympathy because years ago I was in the exact position.
> I'd written the Loki library for C++ that included many components
> deserving inclusion in C++'s standard library. As a first step I asked
> for Loki to be included in Boost. The attempt was met with interest but
> it soon became obvious that I'd need to go through a difficult review
> and make quite extensive adaptations and changes to the library in order
> to be considered. My attitude was "take it or leave it" and that just
> didn't work (and in retrospect, for the better).


> Part of the proposal was a policy-based smart pointer that was superior
> in every way I could think of to other candidates. Yet the proposers of
> those candidates were willing to go through the hard work of improving
> and streamlining their proposals, to the point they got into Boost and
> ultimately into the standard. With time the relative deficiencies of
> that proposal was reduced by adding more kinds of smart pointers, so in
> the end it all got where it is today. In contrast, I was busy with my
> Ph.D. research so I didn't have the time to file away all rough edges.
>
> That was a good lesson to learn. Applied to the situation of today, to
> get anything into the D programming language requires determination,
> humility, and willingness to take criticism and convert it positively. I
> think assuming that Orbit is a great finalized design that others fail
> to appreciate is definitely the wrong starting point. The right starting
> point is asking for feedback, integrate it, and ask again, all in a loop.

Well lucky you. I haven't even got a proper review for Orange. I got some comments and feedback but no formal review. Saying something that I don't want to change anything is plain wrong. I got feedback that slices weren't properly deserialized and that it could be problems if the serializer was templated on the archive. That caused me to completely refactor the library, mostly internal.

I also got the suggestion to allow to set a serializer for a type both for a given instance of the serializer and globally. This also got implemented.

The only thing I haven't implemented that got suggested is support for versions. I haven't done that because I think that this doesn't need direct support because that can be handled by performing custom serialization of a type.

The only thing that could have caused problem is that it also supports D1/Tango. But I have said from day one that if it gets accepted I will remove any traces of D1 and Tango. Most of the code is completely independent of D1/Tango and the code which has dependencies is very local that has nothing to do with the actual design of the serializer.

About Orbit. I started this thread to try and estimated the cost of refactoring Orbit to fit into Phobos/the D distribution. I started with a list, "this is what Orbit uses that does not exist in Phobos. What can we move to Phobos and what cannot be moved to Phobos. What can we do about the rest.". Then the discussion turned into something else.

-- 
/Jacob Carlborg

On 2013-02-15 15:34, Steven Schveighoffer wrote:

> I think holding off on package distribution management because a tool
> doesn't work exclusively with phobos does not sit well with the goal of
> practicality.  Imagine if we required the compiler to be written in D
> before it was "official".
>
> Include the tool, work on the dogfood later.  Note that most of the
> dependencies are built-in to the tool, not external libs.

Thank you.

-- 
/Jacob Carlborg

On 2013-02-15 19:48, Jesse Phillips wrote:

> To add to this. BSD requires the license be distributed with Binary
> forms, Boost explicitly does not. That is their real difference.
>
> This is something Walter wants to avoid with the standard library (I
> agree) but for utility programs it is unimportant since they can be used
> to build the binary and since they are not distributed with the created
> binary there is no need to distribute the BSD license.

Exactly. This won't affect anything built with the DMD compiler and Phobos.

> So the discussion for the library Orbit uses should remain related on
> how much trouble there will be from having an official program use a
> library not part of d-programming-language/tools and friends.

Yes. We can also discussion why that library cannot be part of d-programming-language/tools and friends.

-- 
/Jacob Carlborg