Better controlled HTTP connections

[jankowalski25]

I want to move Http::Request and Http::Response classes outside the Http.hpp file

But why?

My next task is creating Http::Client

How will it differ from the current sf::Http class?

and Http::Server

Are you really going to implement an HTTP server? Why?
Before submitting code without explaining anything, why don't you come on the forum to discuss your plans?

I need better control, so I am trying to create something like this:
Http (base class for HTTP client and server)

• manage connection
• send string
• receive string

Client (inherited from Http)

• send request
• receive response

Server (inherited from Http)

• receive request
• send response

Request (friends: Client,Server)

• request to string (private)
• string to request (private)
• set and get method, uri, etc.

Response (friends: Client,Server)

• response to string (private)
• string to response (private)
• set and get status, body, etc.

[Nexus]

First, you should mention that this discussion continues the pull request #663.

You are still not explaining anything, just listing some classes without telling why you need them. Implementation details are completely irrelevant if you don't explain the semantics. "Better control" is a really too vague in this context -- what exactly cannot be achieved with the current API?

And what's the point in inheriting Client and Server from Http if they don't add anything?

[jankowalski25]

Let's use packets!

I agree that my first plans are complicated to understand and implement. However, now I have second idea. Maybe it will be easier to manage HTTP requests and responses via packets? I am talking about sf::Http::Request and sf::Http::Response inherited from sf::Packet and prepared to manage data as other packets.

what exactly cannot be achieved with the current API?

I can do what I want by using raw bytes, but I need something higher-level than this and lower-level than current code for HTTP.

[Laurent]

Maybe it will be easier to manage HTTP requests and responses via packets? I am talking about sf::Http::Request and sf::Http::Response inherited from sf::Packet and prepared to manage data as other packets.

HTTP requests and responses are text based. sf::Packet deals with binary data. So it doesn't look like we could get something interesting by mixing both

[jankowalski25]

Streams instead packets?

HTTP requests and responses are text based. sf::Packet deals with binary data.

Both are streams based, so it should be possible to access requests and responses by streams (of course higher-level than raw bytes streams and not binary data).

[Laurent]

Can you be more specific about what you suggest? "Stream" is a very vague word, it doesn't mean much outside a specific context.

[jankowalski25]

what you suggest? "Stream" is a very vague word

Current sf::Http class uses HTTP requests and responses instead of raw bytes. I am trying to create general code to replace raw bytes by requests and responses (it may be useful not only for HTTP connections).

[Laurent]

I still don't get it. Maybe some pseudo-code or examples would help.

[jankowalski25]

Example for client and server (not only for HTTP connections):

//client
client.connect(host,port);
while(running)
{
    prepare(request);
    client.send(request);
    client.receive(response);
    doSomethingWith(response);
}
//server
server.listen(port);
server.accept(client);
while(running)
{
    server.receive(client,request);
    doSomethingWith(request);
    prepare(response);
    server.send(client,response);
}

Now I am writing a new code to make it work.

[jankowalski25]

Now I can describe how I am trying to implement mentioned features. I have not finished my code yet, I am just showing my current plans. All suggestions are welcome.
Classes

• sf::Client (abstract class)
• sf::Server (abstract class)
• sf::Message (abstract class)
• sf::Request (inherited from sf::Message, abstract class)
• sf::Response (inherited from sf::Message, abstract class)
• sf::TcpClient (inherited from sf::Client)
• sf::TcpServer (inherited from sf::Server)
• sf::UdpClient (inherited from sf::Client)
• sf::UdpServer (inherited from sf::Server)
• sf::Http (inherited from sf::Message, friends: sf::Http::Request, sf::Http::Response)
• sf::Http::Request (inherited from sf::Request)
• sf::Http::Response (inherited from sf::Response)
• sf::Http::Client (inherited from sf::TcpClient)
• sf::Http::Server (inherited from sf::TcpServer)

Description

• sf::Client
• sf::Server

These classes allow other classes inherited from them sending and receiving plain text (std::string). Data are placed in sf::Request and sf::Response classes.

• sf::Message

Base class for all requests and responses. It contains plain text (std::string). It allows only to read it (const std::string&), changing it is protected - only other classes inherited from this class can do it.

• sf::Request
• sf::Response

They contain functions for changing data between plain text and formatted text.

• sf::TcpClient
• sf::TcpServer
• sf::UdpClient
• sf::UdpServer

They are using TCP and UDP protocols to send and receive data.

• sf::Http

Contain data used in both, HTTP requests and responses.

• sf::Http::Request
• sf::Http::Response

They contain only their own data, not stored in sf::Http. These classes can do more than in current version. They allow to read all fields, also these with unknown names. I also changed methods' names (for example getField() to findField()). Case sensivity is an option - you do not have to use it if you do not need it.

• sf::Http::Client

I am not sure, but only implementation and inheritation diagram for this class should be different. New features are placed in other classes.

• sf::Http::Server

Only basic HTTP server, not something like apache. Not much more advanced than client.

[Nexus]

You are designing a massive class hierarchy, but still don't explain where the additional value compared to the status quo lies. I have the feeling that you're over-abstracting functionality -- inheritance should be used with care in C++, we're not in Java. Please show an example of what your code can do that is not possible with the current API.

Keep in mind that SFML doesn't aim to implement a ready-to-use client/server framework, it only provides the basic building blocks to interact with different network protocols. Further abstractions can be written on top of it -- so the idea. In places where it's not possible to write such abstractions because of an API limitation, there is need for improvement. However, all the possible abstractions themselves do not need to be part of SFML.

[jankowalski25]

Please show an example of what your code can do that is not possible with the current API.

If you are sending raw bytes, current API can do everything, but current HTTP Client cannot:

• show all fields (also with unknown names)
• read created requests (you can for example set method, but cannot get method)
• use case sensitive fields
• preview requests before sending (you cannot check what is added to your requests before sending)

Also if you want to implement something new, you must start from implementing communication. Creating new classes which will change data between plain text and formatted data is not enough to do it.

[binary1248]

Just to provide the connection: What you are suggesting for the HTTP side of things is the topic of the discussion here as well.

use case sensitive fields

http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2

Field names are case-insensitive.

Field values are already treated in a case-sensitive manner by SFML, so I do not understand this point.

The rest of what you suggest, all those additional classes/interfaces, are for me superfluous as well. It can be done in your own code and SFML doesn't have to provide empty interfaces just so you can feel good by inheriting from them. They would serve no real purpose inside SFML or as part of its public API.

You don't need sf::Server to create a server.
You don't need sf::Http::Server to create a HTTP server.
You don't need sf::*****Server or sf::*****Client to create servers or clients, whether you create a server or client depends on the behaviour of your code, and not what you inherit from.

Have you made extensive use of the SFML network module before suggesting all of this? Because if you have, I'm sorry, but I don't see the reasoning behind most of what you said. These suggestions don't solve any real problems, and that is what is important when suggesting features. There are already many client and server applications that have been made with SFML even without these additions.

[jankowalski25]

Just to provide the connection: What you are suggesting for the HTTP side of things is the topic of the discussion here as well.

Yes, I am trying to provide the connection. Thanks for link, I have not read this topic before.

Field names are case-insensitive.

OK, I agree. Thanks for link, I thought they are case sensitive.

It can be done in your own code and SFML doesn't have to provide empty interfaces

If SFML will support more than simple HTTP and FTP clients, I think some code will be the same for each client (for example it may be connecting). Then, a new classes doing this will be necessary to avoid repeating code.

Have you made extensive use of the SFML network module before suggesting all of this?

I was using sf::Http::Client as long as I could. Later, when I had some problems with fields, I started to use sf::TcpSocket. Then, I had problems with receiving data. Now I am trying to implement communication (one send == one receive, something like in packets, but text-based and suitable for all TCP connections).

There are already many client and server applications that have been made with SFML even without these additions.

I hope I will find something useful during reading their source.

//edit: Should I continue discussion about communication in the given topic or here?