Re: [PEPr] +1 for Networking::Net_IDNA

On Wed, 4 Aug 2004 at 14:45:14, Hans L wrote: > Stefan Neufeind wrote: > >>- Matthias seems to be a very reasonable person & sounds like he is > >>going to make whatever changes are proven to be needed. > > > > There are different ways that the class might take. And we already > > discussed that topic a while back (can dig up the archives, if you like). > > And at that point several people agreed upon features that should be added. > > Unfortunately it took David a while to add them, and then came the new > > proposal. I know at the current stage it's late - but the missing features > > ("changes needed" in my eyes) are the reason for -1 on my side. It's really > > not against the "quality of code" or even personally Matthias. > > ...Sounds like it should have been a conditional +1, then. No? Though it's quite a strong condition for me. But you might be right, yes. [...] > >>- As for the bit about copyright, I didn't understand why that > >>contributed to a -1 either way. > > > > It was *not*. As explained above, the reason for the vote was something > > else. Rest of my conditional statement was a "deep source review". > > Ok. I guess I didn't see the relevance of it in your mail, then. No problem, might have been my fault for not clearly separating the major and minor points. > >>- As for PHP4 support being a requirement, of course I disagree with > >>that :) You can always create a backport for PHP4 if you desire. > > > > Agreed! But if it takes quite few changes or maybe even just needs testing, > > I don't see why it should not be doable (read: be done). > > So why don't you do it? As soon as we've sorted out a few general things, David and me will have a look how to make it php4-compatible is possible, yes. > >>If the concern about letting this in is that it precludes a competing > >>implementation, then PEAR needs to fix that issue. > > > > The "competing" is not the point. I just think that the interface and > > direction is completely different. Unfortunately voting has already > > started - and I don't know how we might solve such a "this or that way"- > > voting anyway. > > > > Maybe we find a consense for the package? Or otherwise could we maybe let > > the devs on the list do a "extraordinary" vote which way to go? > > Let both packages into PEAR & they can do battle for users. Sounds fun > to watch :) Not phpclasses.org again :-) (Sorry, no flames intended.) What I meant: We should find a good, not to say the best and most flexible solution that fits users needs and has a clean, extensible API. That's what this discussion is about. > > It was not about the package itself, but with the way it tries to solve the > > problem (the limited API, in my eyes). Also note that there was an > > implementation already present and discussed with the devs. Unfortunately I > > wasn't able to speak up before and it was not yet proposed because David's > > additions were still missing up to today (which were a conditions by a few > > devs, before it should go to a proposal). > > Ok, well, hopefully some sort of consensus can be reached, as you say. > To me this isn't a big deal. I looked at the code & it was clear that a > lot of work went into it. Agreed. > I liked the presence of tests & the PHP5 aspect would make it useful for me. > Matthias seems to be willing to work on changes where they make sense. For > me that was more than enough to warrant +1. Unit-tests might be helpful. That's something we might port over from our own implementation. I have taken over the various examples from the RFC, which seem to be quite extensive refering to the large charset included. Regards, Stefan