The interface for Estonian .ee TLD whois has changed #64

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
2 participants
Contributor

priithaamer commented Jan 5, 2011

Hey, thank you for the feedback. I'm submitting new patch taking your propositions into account. Aliasing parsers makes so much sense, i did not notice that before.

As i still don't fully understand the logic behind AST, i'd leave the regular expressions in to parse the contact information for now but definitely i will have another look at it soon.

Best,
Priit.

Changing estonian .ee TLD whois server and it's format parser accordi…
…ngly to the ongoing reform in .ee domain system.

Defined new parser for whois.tld.ee and aliasing whois.eenet.ee to it.

I believe it was meant to be @registrant_contact ;).

Owner

weppos commented Jan 5, 2011

Thanks Priit!

I'm reviewing the patch and merging the changes.

Owner

weppos commented Jan 5, 2011

I reviewed the commits, applied a few fixes and merged the changes.

Thank you Priit,
Your contribution is really appreciated.

Owner

weppos commented Jan 5, 2011

Updated .ee TLD definition and corresponding parser (closed by 8092c38).

Contributor

priithaamer commented Jan 6, 2011

Thnx for the pull :) I'd also like to parse the nameserver information into Whois::Answer::Nameserver objects but i see there's only one parser that is using it. What is your opinion, shall nameserver object used wherever possible or not?

Owner

weppos commented Jan 6, 2011

What is your opinion, shall nameserver object used wherever possible or not?

Very good question. I prefer to use objects rather than simple strings, however the Whois::Answer::Nameserver class is an exception.
It was introduced by a patch and I never had the time to start converting all the old parsers.

I would ultimately convert the parsers to use that object, because it makes sense.
The object can hold more information than a string, such as the corresponding IPv4 or IPv6.

The current documentation says that the #namesever property returns a String, so it's fine for now.
I would love to convert all the parsers at the same time to keep consistency between objects.

Contributor

priithaamer commented Jan 6, 2011

I have a specific use case where both ip and name of the nameserver are needed, so i'd prefer to use objects. I can help you on migrating parsers. Another option would be to introduce new method that returns nameserver objects without breaking anything. But i guess it depends on how many systems are affected if you change the api.

Owner

weppos commented Jan 6, 2011

I have a specific use case where both ip and name of the nameserver are needed, so i'd prefer to use objects.

That's fine.

I can help you on migrating parsers.

It would be awesome, but let's move to an other ticket. I believe there's already one, but I'm not sure.

Another option would be to introduce new method that returns nameserver objects without breaking anything. But i guess it depends on how many systems are affected if you change the api.

I don't live very much this approach, it tends to duplicate the effort.

The current master branch targets the release 2.0 su I believe this is the right moment to introduce this change, if we want. I won't break BC in a minor or mini release, but I can accept such this BC in 2.0, if documented somewhere.

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment