Proposal: Taking over/up network maintainership

[Merijn Verstraaten]

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

[Dan Burton]

If the long term goal is to completely revamp the api, why not just write a
new library?

Post by Merijn Verstraaten
So, to the best of my knowledge 'network' is currently maintained by
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.
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Merijn Verstraaten]

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

If the long term goal is to completely revamp the api, why not just write a new library?
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.
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Michael Snoyman]

Post by Merijn Verstraaten
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

Post by Merijn Verstraaten
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
"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

Post by Dan Burton
If the long term goal is to completely revamp the api, why not just

write a new library?

Post by Dan Burton
So, to the best of my knowledge 'network' is currently maintained by

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.

Post by Dan Burton
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.

Post by Dan Burton
Short term: fix obvious errors like getContents, cut through the PR

backlog on github to see what can be merged, what needs work, etc.

Post by Dan Burton
Medium term: Improve exception/error handling (network specific

exception type that people can catch), better (async) exceptions safety
guarantees/documentation of safety

Post by Dan Burton
Long term: I would like ditch the current (deprecated) high-level

interface and replace it with modern high level API.

Post by Dan Burton
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).

Post by Dan Burton
Cheers,
Merijn
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Merijn Verstraaten]

Post by Merijn Verstraaten
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.

Honestly, I don't have any strong opinions on this yet. "long-term" goal can just easily be read as "wishful thinking" in the original email. I don't have any concrete plans, so for now it's mostly about "stop things being broken".

Starting a new package/forking network for fast iteration is a nice idea and all, but just leaves everyone else with a broken network package atm.

I was actually doubting whether I should even talk about "long term" plans, clearly it was a mistake to include that. I don't want this turning in an abstract bike shedding discussion about potential future plans.

Cheers,
Merijn

[David Feuer]

A maintainer has arrived, and we should all rejoice! Is a proposal even
necessary? Regardless, Merijn is obviously qualified, and the package
obviously needs a maintainer, so +1.

Post by Merijn Verstraaten
So, to the best of my knowledge 'network' is currently maintained by
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.
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[[e-mail]]

Kazu and I have been mostly derelict in our duties aside from critical bugs
and base conflicts on new versions. +1 from me, but I would advise a strong
preference towards backwards compatibly. Network is at the bottom of many
stacks and breaking changes bubble far.

Post by David Feuer
A maintainer has arrived, and we should all rejoice! Is a proposal even
necessary? Regardless, Merijn is obviously qualified, and the package
obviously needs a maintainer, so +1.

Post by Merijn Verstraaten
So, to the best of my knowledge 'network' is currently maintained by
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.
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Kazu Yamamoto (山本和彦)]

Hello Merijn,

Post by Merijn Verstraaten
So, to the best of my knowledge 'network' is currently maintained by
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.

As Evan explained, Evan and I are the maintainers. But our activities
are limited to bug fixes, documentation updates and catch-up to new
GHCs.

I welcome you to be a maintainer.

I think we need a guideline for contributions. hs-tls is doing this
very well. See:

https://github.com/vincenthz/hs-tls/blob/master/CONTRIBUTING.md

The contributors of hs-tls review others' PRs and its history stays
linear. It's really nice.

Post by Merijn Verstraaten
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).

Evan and I don't have milestones for new features. If you want to
develop the network library aggressively, please create milestones on
github so that contributors can understand what you are trying to do.

As Evan said, the backward compatibility is important for this
library. And I would support Michael's idea: "deprecate the old
high-level interface, and add a new, better designed high-level
interface".

--Kazu