Optimize archive on Context Menu

[davidsplash]

plugin support like irfanviews plugins for graphics is need here so you can install the formats you use and not the ones you don’t. Saves on downloading and of cause helps people who want a certain file type, which at present pa does have.

This would solve the problem of having too big a download for pa.

[Jr heuwing]

This is already being asked.

http://www.powerarchiver.com/forums/showthread.php?t=111&highlight=plugin+support

The only thing i can’t understand, you started the thread listed above ? :confused:

Are you forgot about it ?

[davidsplash]

yes i started it but to keep the idea around or open as they say i decidee to post it again. Plugin aqrchitecture works for irfanview. All you would need is one plugin for each format i.e one for both extracting and compressing. Well as pa is updatable i say plugin arcvhitecture would make pa more in line with other archivers. If one student could do this idea on a graphics viewer/editor then i can’t see why pa can’t do the same thing.

Once a new version comes out they can discontinue support for the old one thus giving pa more flexability. I never uae some of the formats pa offer but i do use some they don’t

I have to have winuha on my system for uha, ( compressing and extracting)and suffit for sit files, just for extraction these.

If pa had a pluginb architecture We might just if avaliable download the file formats like these.

This would stop people saying pa is becoming bloated. Each version comes up with archive formats i need and don’t need which in turn makes it a big download, thats if your a dailup user which some customers here unlike myself are.

The benifits outweigh the cons

What happens for example 7zip specification or rar extraction gets changed pa has rto write a new version of pa each time this happens with more features, just to suit these formats. If they used plugin architecture they would only need to possibly update the plugin for that format. They could also let other people write plugins for pa at the same time. Though distribution will only be allowed via the pa web sit once compatability is established. this would spawn more format support and give pa a more diverse customer base. Along these lines it will also make them market leader as they once were in archive software inovation

what does everyone else think including the author

[Ricco]

Yes PA is larger than xxxRAR for downloading…

But I’m wondering…
Is it really caused by the filetypes supported (i.e. plugin architecture can be implemented to remove unwanted filetype(s) support from the download)
Or it is caused by the programming language used?
PA is developed using Delphi and I think xxxRAR is written in C/C++. Generally C/C++ compiles code smaller than Delphi does. It could be the reason.

[spwolf]

@Ricco:

Yes PA is larger than xxxRAR for downloading…

But I’m wondering…
Is it really caused by the filetypes supported (i.e. plugin architecture can be implemented to remove unwanted filetype(s) support from the download)
Or it is caused by the programming language used?
PA is developed using Delphi and I think xxxRAR is written in C/C++. Generally C/C++ compiles code smaller than Delphi does. It could be the reason.

both actually, although PowerArchiver is pretty optimized for an Delphi program (as you can see from relativly small size).

Also, our interface is graphically heavier, help is bigger, considerably more features everywhere (ftp, backup, ppm, pae, tools, etc) and we also make great deal of effor to lower installation size (and we have always done this).

With less features, PA would probably be 1 MB less, but that would not be the point, would it be? :-).

As to the plugins, yes… eventually…

[jowood]

@Ricco:

Or it is caused by the programming language used?
PA is developed using Delphi and I think xxxRAR is written in C/C++. Generally C/C++ compiles code smaller than Delphi does. It could be the reason.

WinRAR is developed using C++ Builder and Windows API instead of VCL and many 3rd party components.