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.

There is no need to be complete rude, nor is there a need to reply three times in a row, one will suffice.

In addition there is nothing wrong with the built-in $compress/$decompress() functions, if they arent working for you then obviously your doing something wrong.

In address to 'mIRCs limitations', simply dont use it if you want gzip streaming support, or, since i have 'no idea what i'm talking about', you can see a thread here about creating send/recieve functionality with Sockets, and create your own wonderful gzip steam with it.

Furthermore, XP, or certainly not mine anyway (XP-SP2) doesnt support .gzip format files, however does support zip.

Eamonn.

sorry m8, but he knows how to stream with sockets, his web server proves it.



about this, maybe he thinks like me, what is the use of this methods the way they are? What is they portability? What is they compress method? Raw meaning what, pure Huffman compression?

This is all about speed and portability… the 1º because dll has some considerable cost in time for intensive use and the 2º because it is good to be able to interact with other applications.

Thanks for your time reading this thread.
Tontito

- As I already pointed out above, they use the Zlib compress/uncompress methods.


- If you were really concerned about speed and portability you wouldn't be using mIRC scripting to write a web server. A speed difference between a well coded DLL and calling an internal GZip identifier would be negligable. mIRC scripting itself would be the major limiting factor under 'intensive use'. I don't see why interacting with other applications is a good thing when those applications and the method of interaction are completely detached from IRC.

I agree with you that mirc scripting isn't the right language to write a web server, but you know how guys like me and oracel are, we are always trying to make almost impossible stuff with mirc.

About the negligible time you say that there is in the use of dlls, i can only say that i manage to script (in mirc) the functionality of a dll (mhtml dll) and it became much faster. It is one example.

Seems that the dll call is very slow, even with the dll in memory.
Thanks again

Speaking as a network admin, let me put a scenario to you....
Do you consider, as a newbie user, having just purchased a new machine with a router. That configuring that router for file transfer using DCC is an easy matter with all the numerous ports.
:::::::::::::::::::::::: Disclaimer :::::::::::::::::::::::::::::::::::::::::::
For you to be able to share your files on IRC
The following ports on your machine must be open
59, 1024 to 5000, 6667 to 6669, http 80 and 8080. Also ports 110 and 113.
Or you may choose to use the DMZ function in your router
In which case, don't forget you'll need to forward port 113 to your local ip
If the equipment (router etc.) came packaged with your Internet connection.
We advise you to consult the supplier and seek advice from them.
If you choose to open these ports yourself we take no responsibility.
We are merely advising you what is required.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Or do you consider that using a webserver, using just port 80 makes life a lot easier.

And before you start on the subject of Mirc being intended as a chat line, this is the real world.

I run tontito's much improved webserver, to great effect I might add, as do many others on my network.

All my request was intended to do was to make Mirc more user friendly.

Mirc is for end users not coders, and a webserver is a welcome addition and an alternative to DCC.

Hardcore maniac mirc scripting forever! \m/ (^-^) \m/

yep, there is one in the official web page GZIP seems free to me...