Messages

1

Feature requests / Re: Better controlled HTTP connections

« on: August 12, 2014, 12:20:58 pm »

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?

2

Feature requests / Re: Better controlled HTTP connections

« on: August 12, 2014, 07:49:49 am »

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.

3

Feature requests / Re: Better controlled HTTP connections

« on: August 11, 2014, 09:33:54 pm »

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.

4

Feature requests / Re: Better controlled HTTP connections

« on: August 08, 2014, 07:47:31 pm »

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.

5

Feature requests / Re: Better controlled HTTP connections

« on: August 07, 2014, 08:57:24 pm »

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).

6

Feature requests / Re: Better controlled HTTP connections

« on: August 07, 2014, 03:40:46 pm »

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).

7

Feature requests / Re: Better controlled HTTP connections

« on: August 05, 2014, 10:27:57 am »

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.

8

Feature requests / Better controlled HTTP connections

« on: July 17, 2014, 11:12:29 am »

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.