Httpd design issues about ceylon-sdk HOT 13 CLOSED

Furthermore, I also have some doubts about naming.

1. Why is it HttpRequest, HttpResponse? Does ceylon.net have other kinds of Requests and Responses?
2. Why is it WebEndpoint and WebEndpointConfig? Does ceylon.net have other kinds of Endpoints and EndpointConfigs?
3. Why is it HttpdStatusListerner? Are there other sorts of StatusListener? Also note the misspelling ;-)
4. We don't use abbreviations in the SDK, therefore Config should be Configuration.
5. I'm also very suspicious of the name of the interface Httpd. Is that a word?

from ceylon-sdk.

I think we should be putting all this in a ceylon.http module (e.g. ceylon.http.client / ceylon.http.server) rather than it being a package of ceylon.net. After all there are plenty of other protocols, and it would be unreasonable to make them all packages of ceylon.net.

And I agree that we should try to avoid the term 'httpd' in favour of 'server', which will be more obvious to many people, is pronounceable, and offers a certain symmetry in conjunction with the term 'client'.

from ceylon-sdk.

In principal I agree with the above, just that I don't see how "it would be unreasonable to make them all packages of ceylon.net". Why would that be unreasonable?

from ceylon-sdk.

Well, I guess we're unlikely to support a great many protocols in the SDK, so maybe it would not actually be "unreasonable". But in theory we end up with a package (or two) for each protocol, and imho it gets a bit silly having nested packages like this:

• ceylon.net.http
• ceylon.net.smtp
• ceylon.net.xmpp
• ceylon.net.ftp

where there's no dependency of the subpackages on each other, only on the parent package.

The whole point is that http provides abstractions I can use (mostly) independently of tcp/ip, so having those abstractions in their own module makes sense to me. After all, in theory I could write an http 'server' that uses inetd to handle the network interaction.

from ceylon-sdk.

Well, I would expect inetd to be in net as well :)
But even so, an http client/server without some kind of network communication seems a bit far-fetched right?

For it's just that if we start putting everything in the toplevel name space we'll end up with many dozens of modules and no grouping, no way to easily find related things, so http will be next to regexp, next to serializing, next to xml parsing, etc, personally I like things a bit more organized

from ceylon-sdk.

I agree with quintesse, I prefer ceylon.net.http than ceylon.http

I also found that server would be clearer than httpd

from ceylon-sdk.

What do you think about moving to ceylon.net.http.client and ceylon.net.http.server ?

from ceylon-sdk.

Sounds good to me.

from ceylon-sdk.

+1

Sent from my iPhone

On 08/03/2013, at 11:00 AM, Matej Lazar [email protected] wrote:

What do you think about moving to ceylon.net.http.client and ceylon.net.http.server ?

—
Reply to this email directly or view it on GitHub.

from ceylon-sdk.

This is done, right?

from ceylon-sdk.

Can I close this issue or was there something else remaining?

from ceylon-sdk.

You can close it. @gavinking refactored API, based on his comments ;)
Packages has been renamed too.

from ceylon-sdk.

Thanks.

from ceylon-sdk.