Proposal: Taking over/up network maintainership

[Michael Snoyman]

> Why keep around a deprecated high-level interface and recommend people
use the low level one.

How about a third option: deprecate the old high-level interface, and add a
new, better designed high-level interface? That way you keep backwards
compatibility for existing code, while allowing a new API to come into
existence.

Personally, in these kinds of situations, I usually recommend starting the
new API off in a separate package to allow for more rapid API iteration
without inflicting breaking API changes on the original package, and
then—once the API has stabilized—consider including it in the original
package.

Michael

On Tue, Oct 10, 2017 at 5:36 PM, Merijn Verstraaten <merijn at inconsistent.nl>
wrote:

> Hi Dan,
>
> The long term goal is not to revamp the entire API of network, just the
> high-level interface in the Network module. Currently (actually, for the
> entire past, like, 5 years I've been using network), the documentation of
> the Network module has stated:
>
> "This module is kept for backwards-compatibility. New users are encouraged
> to use Network.Socket instead.
>
> Network was intended as a "higher-level" interface to networking
> facilities, and only supports TCP."
>
> Why keep around a deprecated high-level interface and recommend people use
> the low level one. Seems much better (long-term) to overhaul the high-level
> interface in Network so that it actually becomes recommend over writing
> code using Network.Socket itself.
>
> Cheers,
> Merijn
>
> > On 10 Oct 2017, at 15:51, Dan Burton <danburton.email at gmail.com> wrote:
> >
> > If the long term goal is to completely revamp the api, why not just
> write a new library?
> >
> > On Oct 10, 2017 04:29, "Merijn Verstraaten" <merijn at inconsistent.nl>
> wrote:
> > Hi hackage admins & libraries@ readers,
> >
> > So, to the best of my knowledge 'network' is currently maintained by
> libraries@/the community, which is code for "not maintained". I've
> previously entertained the thought of taking up maintainership, but so far
> was held back by the fact that I don't do windows dev experience. I've
> discussed this in #ghc before and the consensus was that *nix only
> maintenance is probably still better than no maintenance.
> >
> > I was inspired to finally write this email and try to take up
> maintenance after spending all day yesterday tomorrow debugging an issue in
> my code, only to realise that Network.ByteString.Lazy.getContents will
> literally *always* crash/throw an exception when used.
> >
> > My plans are to:
> > Short term: fix obvious errors like getContents, cut through the PR
> backlog on github to see what can be merged, what needs work, etc.
> >
> > Medium term: Improve exception/error handling (network specific
> exception type that people can catch), better (async) exceptions safety
> guarantees/documentation of safety
> >
> > Long term: I would like ditch the current (deprecated) high-level
> interface and replace it with modern high level API.
> >
> > Now, the biggest problem is that I don't have experience developing on
> Windows and neither the time nor the motivation to get started with that,
> so I will need someone to take up co-maintainership of the windows parts
> (I'll probably send an email about this to -cafe if people are supportive
> of me taking up maintenance).
> >
> > Cheers,
> > Merijn
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20171010/fb033449/attachment.html>