Forums Feature Suggestions gzip compression

Be nice to have gzip compression introduced

i subscribe that request

Where exactly would you like gzip compression? DCC transfers? As far as scripting goes, there's already $compress() and $decompress()

Well m8, for my case, gzip is a format known by almost all browsers, now you can imagine what i am doing...

p.s i don't like much of dlls

gzip isn't known by most "browsers", infact gzip isnt even known by windows, its known by *nix operating systems, but apart from that, you need to install software that reads/writes it.

Eamonn.

gzip is used by all mainstream browsers AFAIK. It's a method of runtime compression used by web servers if the web client (browser) sends an Accept-Encoding header containing gzip.

yes gzip streaming but not in the sense that, you can download and open a gzip application.

and if hes talking about runtime compression for dcc, then as qwerty said, compress/decompress already exist.

The type of compression (i.e. gzip or not) makes absolutely no difference if its "recognised elsewhere" since its totally internal, i.e. compress on send, decompress on recieve, the user knows no different.

Eamonn.

No, i was not talking about dcc runtime compression; i am talking about page compression and send it to browsers.

Yes, i am building a web server!
Tontito

Signed! As I am also working on a webserver (MotionWS), this would come in extremely handy. Streaming gzip compression is not practically possible without it being built in to mIRC (or scripted! ).

I bet there are plenty of open source solutions for this. If Khaled wants to avoid any licensing, there might be a possibility to split the gzip part into a dll that can be freely downloaded in addition to mIRC.

Not to be rude or anything but, mIRC is a text-based chatting application, why would it have gzip compression built in so people can build a webserver, wouldn't that be silly since neither of the 2 topics are related?

i.e. text-based chatting, and file sending, i can see a resemblance. (sp), but text-based chatting and webserver, just seems far fetched.

Eamonn.

Hey, we like to exercise our brain at the free times, doing interesting things, and you don't imagine the amount of people that use this addons...

I'm not saying that it isnt useful to some, infact i've coded a few webservers in my time, however what i'm saying is that gzip built-in to mIRC would be like installing text-based chat into internet explorer, since Internet explorer is a browser not a chatting client, as mIRC is a chatting client not a browser.

There's nothing stopping you distributing gzip.exe with your script, since it does come with a good amount of files and directories already (if your new version is similiar to your old, (downloaded it to see)), and using COM Objects to load it so that you dont see a dos window open when you gzip a file.

Eamonn.

well mozilla and opera have chat clients
and i believe the $compress function has more use compressing with gzip then with that raw compress method that probably can only be used by mirc it self.
It is my point of view of course...

You are missing the point, and making absolutely awful suggestions in the process. I mean, gzip.exe?? There are already plenty of (g)zip dll's available, but they only zip files. They don't do streaming compression. I have not given the possibilities regarding writing such a dll any thought, but I doubt that it would function in a satisfactory way. This of course due to mIRC's numerous limitation. I hope this helps your understanding of this topic.

At this date, gzip is the only mainstream http compression method. And even at that experimental. $(de)compress is some flawed implementation of some algorithm of unknown origins. Who uses it, anyway? I remember trying it, and it basically doesn't work, unless it's your lucky day.

I mean, jesus what universe do you live in? Have you even TRIED Windows XP? It has built in gzip support, which you obviously didn't seem to know.

This is the third of your posts I am replying to, and I can see now that you generally have no idea what you are talking about. You are just adding replies for the sake of provocation and trolling. I am sure the moderators will concur with me on this point if you continue adding posts stripped of relevant content and reasonable arguments.

Since when was Zlib an 'unknown origin'? And since when were Zlib's compress/uncompress (sic) methods flawed? $compress and $decompress work just fine for me.

It would be quite simple to create a DLL that filled a binary variable and triggered a signal that could then be used to send the contents over a socket or do anything else. No functionality issues whatsoever.

The origin was unknown to me, I am sorry I did not specify this clearly. Additionally, the tests I have done with $(de)compress have failed when handling (de/compressing) large amounts of data. This may have been fixed in recent versions, but I have no indication of this. Feel free to conduct such tests and post the results.

I would also like to point out that I did not state that Zlibs "methods" are flawed, but rather that mIRC's $(de)compress identifiers are or were flawed. I would like to make this absolutely clear.

That may well be the case, I am not aware whether or not mIRC dlls can return binary data, but if it is, then of course this would be a simple matter indeed.