RTB sucks I'm making a better one!

[Ephialtes]

The ID list especially is very slow.

The ID list is just slow because it uses an old database schema. Once I have the time to update it, it'll go super fast like the rest of the site.

There are no speed issues anywhere else on the site.

[Ad Bot]

[M]

Where exactly did he need the encoding?

Because sending a backslash followed by an x and then a hex value is going to violate UTF-8 encoding which he is apparently bound to using because of the specification he chose.

However by the logic involved in the way Ephi's explained that, it's more like "If you only send characters that UTF-8 represents with a single byte, it's not valid UTF-8 encoding because it represents other characters that you didn't use at all with multiple bytes". After all, if sending a literal backslash is going to violate the specification, perhaps he should pick a new one.

[Chrono]

However by the logic involved in the way Ephi's explained that, it's more like "If you only send characters that UTF-8 represents with a single byte, it's not valid UTF-8 encoding because it represents other characters that you didn't use at all with multiple bytes". After all, if sending a literal backslash is going to violate the specification, perhaps he should pick a new one.

Blame Torque for being inefficient.

[NickTheSushi]

Kalphiter why are you obsessed with either trying to one-up everyone or post information about Blockland? I mean, it might be interesting (the information you post) but it isn't like it's some reputation-adding information or anything.

I'd love to see how this goes down.

[Ephialtes]

Because sending a backslash followed by an x and then a hex value is going to violate UTF-8 encoding which he is apparently bound to using because of the specification he chose.

However by the logic involved in the way Ephi's explained that, it's more like "If you only send characters that UTF-8 represents with a single byte, it's not valid UTF-8 encoding because it represents other characters that you didn't use at all with multiple bytes". After all, if sending a literal backslash is going to violate the specification, perhaps he should pick a new one.

I explained quite coherently why I wasn't going to use your idea, and I gave a very good reason for it. I think you should drop it now, encoding functions are in v15 and they work just fine.

[MtnDew]

Yay :D something better than RTB.

[Chrono]

Yay :D something better than RTB.

I'm not sure what your problem with RTB is.

[Ephialtes]

I'm not sure what your problem with RTB is.

Space Guy failed some of his add-ons he submitted because Pandan doesn't know how to submit quality things, so he started boycotting RTB.

[Deriboy]

Kalphiter's avatar makes it hard to take him seriously.

[Kalphiter]

Aren't you only dealing with characters #0-255? (well, really starting from hex 21).

I also do notice that there isn't a spot for hačeks (š ǒ ǐ...)
Are these an example of symbols that go above 255?

[M]

I explained quite coherently why I wasn't going to use your idea, and I gave a very good reason for it. I think you should drop it now, encoding functions are in v15 and they work just fine.

You did explain, however

You are proposing I totally hack up an XMPP server to completely violate the RFCs (which are put in place and strictly adhered to in order to make sure the server can correctly interact with all the other servers and clients)

What I said was to send, from Torque to the server, the literal string "\x**", not as an escape sequence, as a string of four separate characters.
It's perfectly valid UTF-8 as it doesn't represent any single character with an incorrect value.

You would of course have to convert any character which uses multiple bytes into the \x** sequence for Torque clients, and the sequences into the appropriate character if applicable for non-Torque clients. But instead you'd rather modify someone elses product (Blockland) than your own XMPP server.

Yes, it requires some work. Yes, you have a better solution now which needs to be waited on. However as for violating the RFCs, I'd be pretty worried if the RFCs were violated by backslashes, 0-9, A-F and X.

[Ephialtes]

You did explain, howeverWhat I said was to send, from Torque to the server, the literal string "\x**", not as an escape sequence, as a string of four separate characters.
It's perfectly valid UTF-8 as it doesn't represent any single character with an incorrect value.

You would of course have to convert any character which uses multiple bytes into the \x** sequence for Torque clients, and the sequences into the appropriate character if applicable for non-Torque clients. But instead you'd rather modify someone elses product (Blockland) than your own XMPP server.

Yes, it requires some work. Yes, you have a better solution now which needs to be waited on. However as for violating the RFCs, I'd be pretty worried if the RFCs were violated by backslashes, 0-9, A-F and X.

You understand that there are XMPP clients in so many languages, right? You also understand it is an absolutely impossible  task to work out escape sequences for all of them and then modify the server to correctly escape everything depending on where the message is going right? It is a totally unworkable idea (note an idea, not a solution) and I don't know why you're being so stubborn about it.

[Marcem]

The server isn't as slow as crap.
And, once again, Ephialtes wouldn't have the time to keep up.

Are you comparing RTB and this?  How do you know the RTB server speed when you can't use it?

[M]

You understand that there are XMPP clients in so many languages, right? You also understand it is an absolutely impossible  task to work out escape sequences for all of them and then modify the server to correctly escape everything depending on where the message is going right? It is a totally unworkable idea (note an idea, not a solution) and I don't know why you're being so stubborn about it.

It doesn't need to escape for other clients unless they're also not using correct UTF-8 encoding. It only needs to escape for Torque. How the forget can you not understand that?

Torque does not by default support the correct encoding. You have said this. The server needs to change characters that Torque cannot represent in UTF-8 into \x** to output to Torque clients, and when Torque input is supplied, you need to change \x** into the appropriate UTF-8 characters. No other clients need to have their output converted because assumedly any client with XMPP support has proper UTF-8 support for using it. Their input needs to be converted to be sent to Torque.

I am not being stubborn in thinking you will use this. You have your encoding functions. I am being stubborn in that I don't think you've got it right.

Torque -> ASCII Input -> Server -> UTF-8 Output -> Other Clients
Other Clients -> UTF-8 Input -> Server -> ASCII Output -> Torque
Torque -> ASCII Input -> Server -> ASCII Output -> Torque

[Jellypuddle]

He's obviously trolling.