PDA

View Full Version : par files versus separate pm files in plugins ?



erland
2008-09-12, 04:47
Could someone with a bit more perl knowledge than me explain why we have chosen to package all code in the third party plugins as a par files ?

Is there any advantage with this compared to distributing the plugin as separate pm files ?

I think someone earlier mentioned that it will make downloading easier when we make the plugin installation web interface planned for 7.3. However, we still need to download things that are outside the par file like HTML interface templates, so I suspect we are going to package everything in a zip file (or similar) anyway.

The big disadvantage with par files as I see it is that it makes it a lot harder to start with plugin development, you will need to know a lot more since you have to unpack the PAR file to get access to the perl code.

So could someone enlighten me please ?

Yes, I know that I don't have package my plugins as PAR files, but it has been stated earlier that PAR files is the correct way to do it. If you don't want to use PAR files it also means that you can't use the PluginBuilder tool provided by Logitech.

gharris999
2008-09-12, 07:19
My guess is that it was exactly as you said: "it will make downloading easier when we make the plugin installation web interface planned for 7.3." Except, I think that originally it was thought that the whole user plugin install infrastructure would be in place long before now.

The whole thing was supposed to be modeled after the Firefox plugin scheme, wasn't it? If you look at firefox plugins, (in windows, look at C:\Documents and Settings\username\Application Data\Mozilla\Firefox\Profiles\9pb2os8z.default\ext ensions\) you'll see that the actual extension code and resources are packaged in "jar" files, which are actually zip files, just as the "par" files are.

I'm not sure where the "par" extension came from, but I'm guessing that it was to distinguish them from "jar" files. Also "jar" is a java extension. I'm guessing that the "p" in "par" is for "perl." I'm also guessing that to make this whole infrastructure work, SC is going to have to register a "par" content handler with the OS & folk's browsers at SC install time. Click on a "par" file on a web page, the browser downloads the content and then fires off the registered perl app that does the actual install. I'm also guessing that most of the hold up here has had to do with thinking through how to set up the repository for the user plugins, how handle the headaches of having a responsible gate keeper for that repository, and the potential legal ramifications of all of the above. If no repository for user plugins gets set up, then the installer app needs to have a suitably draconian legal language splash screen absolving Logitech and all SD employees from any consequences of installing a plugin for you, up to and including whether or not the plugin burns down your house.

I think that the firefox install mechanism extracts all the needed stuff from the "jar" file and I assume that the SC mechanism would do likewise. I don't think it will be the case of "embedding a par within a zip." The par file alone ought to do the job...at least I think that's how the firefox mechanism works. If you download a firefox extension using IE, and change the extension from jar to zip and extract the files, you can see that there's no other jar file in there. I imagine that folks thought the SC mechanism would work the same way: everything gets packaged in a "par" file and the installer extracts all the bits that need to be extracted at install time vs. the stuff that can wait to be extracted at run time. Keeping the executable code in the par file until run-time would add a tiny (and probably ineffectual) bit of security against malware on a windows system from introducing objectionable / spurious statements into what otherwise would be a completely unsecured bare perl script.

Personally, I've never used the plugin builder either in my own little plugin or in adapting other's 6.x plugins for my own use in 7.x. I've always just used an on-line GUID generator for the <id> value in install.xml and just ignored the whole par file thing.

Once the plugin install infrastructure is in place, I'll have to play catch-up.

erland
2008-09-12, 07:43
The par file alone ought to do the job...at least I think that's how the firefox mechanism works. If you download a firefox extension using IE, and change the extension from jar to zip and extract the files, you can see that there's no other jar file in there. I imagine that folks thought the SC mechanism would work the same way: everything gets packaged in a "par" file and the installer extracts all the bits that need to be extracted at install time vs. the stuff that can wait to be extracted at run time.

If everything was package into the par file I completely agree and then it would make a lot of sense, but SqueezeCenter ONLY package the code in the par file and other resources is handled outside of it. So a plugin builder first builds the par and then package the par together into a zip which also include HTML files and images.

I don't think the par file is unpacked on the disk after it has been installed, I think perl is able to read the perl modules directly from the par file. I'm guessing that this maybe work with perl files but not for resources such as HTML files and images needed for the plugin web interface ?

If it doesn't work for resources, I don't see the need for the par file at all. It would be enough with just the zip file that contains separate resource files and separate pm files.

Does anyone else have any clue why we have/need the par file packaging ?

Dan Sully
2008-09-12, 08:57
* erland shaped the electrons to say...

> Does anyone else have any clue why we have/need the par file packaging

The original idea was that it was all the resources, just like Firefox.

-D
--
<dsully> please describe web 2.0 to me in 2 sentences or less.
<jwb> you make all the content. they keep all the revenue.

erland
2008-09-12, 09:10
* erland shaped the electrons to say...

> Does anyone else have any clue why we have/need the par file packaging

The original idea was that it was all the resources, just like Firefox.

Is there some limitation in perl/par or in the SqueezeCenter code or its libraries that results in that we can't or don't want to distribute the HTML templates, java scripts, images and other files in the par file ?

I suppose there is some reason why the PluginBuilder have chosen to only include the code and not the other resources in the par file today ?

gharris999
2008-09-12, 11:00
I think what Dan is suggesting is this:

The current plugin builder is an alpha. Once the install infrastructure is put in place, the plugin builder will be modified so that, yes, everything goes into a .par, not a .zip. The installer then has the responsibility to extract and put in place all the pieces in the par that perl can't extract at runtime. I'm pretty sure the firefox .jar installer works exactly this way.

I know you'd rather hear this from someone who really knows, not just my idle speculation, so I apologize for not being able to keep my yap shut.

peterw
2008-09-12, 16:47
The original idea was that it was all the resources, just like Firefox.

I share Erland's preference that the .pm files be "unpacked". One of my plugins (PowerCenter) *requires* some files to be unpacked (compiled exes) and in discoverable locations. A dir structure like
Plugins/Foo.par
Cache/Plugins/Foo/Plugin.pm
would be fine/great for me.

-Peter

jerrberr
2008-10-14, 08:09
I don't care whether you use separate .pm files or .par archives. My problem is that I can't figure out how to extract the .pm from the .par.

Any help is much appreciated. Is there a solution for winxp?

EDIT - Got it. Change the .par extension to .zip and unzip - easypeasy

Grotus
2008-10-14, 08:55
par files, like jar files are just ZIP archives. So, if your ZIP
program won't open it as is, just add a .zip to it and it should open
right up.

On Oct 14, 2008, at 8:09 AM, jerrberr wrote:

>
> I don't care whether you use separate .pm files or .par archives. My
> problem is that I can't figure out how to extract the .pm from the
> .par.
>
> Any help is much appreciated. Is there a solution for winxp?
>
>
> --
> jerrberr
> ----------------------------------------------------------------------
> --
> jerrberr's Profile: http://forums.slimdevices.com/member.php?
> userid=19400
> View this thread: http://forums.slimdevices.com/showthread.php?t=52529
>
>