ICANN/DNSO
DNSO Mailling lists archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

[registrars] FYI: Fw: [Epp-rtk-devel] Release of 0.4.0 just around the corner


This may be of interest to you or someone within your organization. The
EPP-RTK project website is located at http:/epp-rtk.sourceforge.net

-rwr

----- Original Message -----
From: "Daniel Manley" <dmanley@tucows.com>
To: <epp-rtk-devel@lists.sourceforge.net>
Sent: Friday, September 28, 2001 12:26 PM
Subject: [Epp-rtk-devel] Release of 0.4.0 just around the corner


> Hi everyone,
>
> lyin and I have been working on release 0.4.0 of the Java RTK for a
> while now.  Originally for the sake of keeping up with the IETF, but
> since Neulevel has announced that their protocol XRP is simply going to
> be EPP with extensions, we've been working to get it ready for the
> launch of live .biz.  Neulevel has also announced that BEEP will not
> initially be used as a transport, so there's no emergency to write a
> BEEP transport handler for the RTK.  Neulevel does have their own RTK,
> but implementing it would mean writing all new registry agents and going
> the pains of testing and bugs.  Using the SourceForge RTK should give
> registrars a head start to get online quickly.
>
> What we've done for release 0.4.0:
>     - upgraded to the IETF's 04 EPP and 02 Domain/Contact/Host release
> of EPP (hence where I've gotten the term "EPP 04/02")
>     - merged bug fixes and improvements from the epp-pre02 CVS branch
> (the 0.3.x line of the Java RTK)
>     - revamped the protocol/transport internals of the EPPClient class
>
> The third point is the most interesting in my opinion.  We've created a
> "transport" package (a la C++ RTK -- thanks to GNR for the inspiration!)
> under com.tucows.oxrs.epp.rtk.  In there you'll find EPPTransportBase,
> EPPTransportTCP, EPPTransportTCPTLS and EPPTransportSMTP.
>
> The EPPClient no longer uses an integer protocol instance variable to
> create a socket.  Rather, it now looks for rtk.properties and the
> rtk.transport property.  This property is the name of the class to use
> for the transport layer (eg EPPTransportTCPTLS).  This class is
> instantiated when connect() is called in the EPPClient.  The transport
> layer handles connection, disconnection, and writing to and reading from
> the server.  Those are actually abstract methods in EPPTransportBase.
>
> The reason all of this:  to be able to introduce any number of
> transports into the RTK.  We've create EPPTransportSMTP as an example
> (unfortunately, it really doesn't do much yet since there are no
> registries that currently use SMTP).  EPPTransportBEEP would be a
> perfect practical extension of this framework (any volunteers?).
>
> Users who are currently using the 0.3.x EPPClient's default TLS/SSL
> connection won't see a difference here.  Those that create their own
> secure socket and use setSocketToEPPServer() will have to create a
> transport object and call EPPClient's setTransport() method instead.
>  Hopefully these are minor changes for those affected.
>
> Currently I'm working on documentation (user guide and Javadocs).  Take
> a look at the code in CVS.  Any feedback is welcome.
>
> Thanks,
> Dan and Larry
>
>
>
> _______________________________________________
> Epp-rtk-devel mailing list
> Epp-rtk-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel



<<< Chronological Index >>>    <<< Thread Index >>>