66 replies to this topic

[Rob van der Does]

Let's turn it around: the problem is pipzap; AMS doesn't run on all PLi-based images.............
So if it would be possible to 'repair' the plugin, we are done.

So again (going around in circles): before spending (a lot of) time on this, it would be good to know what AMS adds to PLi.

But than again: if you're not interested in solving your original problem anymore, it's fine with me........

Edited by SatKiekerd, 19 June 2012 - 15:49.

[WanWizard]

Let's cut this story short, because we're going around in circles. We are not going to modify the image. Period.

Plugins need to be compatible with the image, not the other way around. Especially if it's not a plugin but a collection from several authors, glued together, of which some do not allow the use on all OpenPLi supported platforms.

If you have reasons to believe that PipZap could be implemented better that it is now, by all means tell us and perhaps that might be a reason for a modification.

[rtzhjgg0]

If you have reasons to believe that PipZap could be implemented better that it is now, by all means tell us and perhaps that might be a reason for a modification.

@WanWizard
I will try to list some reasons. If you remove the old code and use the PiPzap-plugin you will have this advantages:

- no more eventual conflicts with other software (becouse the patch is defacto old).
- PLi users can decide to install PiPzap or not.
- in PiPzap-plugin you can switch/configure three elements more than with the actual patch:

1 use or not STOP-Key to enable/disable pipzap mode.
2 show or hide indicator label in the opposite corner when pipzap mode is enabled.
3 show or hide in Plugin menu.

Is something wrong in this list?

[littlesat]

Our pipzap code is not the problem, but ams is the problem, they are not compatible with our pipzap code. There is no reason to adapt our pipzap code for just one plugin. In adition it is not our fault the dmm based images might differ more and more. I inverstigated ams and I must conclude it looks unstructured has different licenses and is partly closed source all argument pli should not adapt. Someone could better made changes that have a clear license and is fully opensource..... As pieterg already mentioned we will not remove our good old pipzap code.

[rtzhjgg0]

Amen :-)

[jeffphil]

Amen :-)

OK here is my take on this discussion

1 there is a problem with running AMS on pli images because it is incompatabile with the pipzap implimentation used in pli

2 AMS is a collection of plugins stiched together by an "author"????

3 Apart from the problem with AMS the pipzap code in pli has no other issues.

The solutions are

1 Modify the plugin to work with pli

2 modify pli to work with the plugin

Now in logic if we look at the benifits to the greatest number of users which is what open source is all about I see this issue only affecting 1 person so far so realistically why should pli modify the image when their time is much better spent advancing the image in other areas to benefit more people.

I would also suggest that if AMS runs on other images you could use 1 of those but I guess that like myself you have found pli to be a much better image so here is what I think you should really do

Use the work around and run with the pipzap plugin and suggest to the author of AMS he looks at the support and advances made by the openwebif team by open source development. Or if you really think that pli should change pipzap make a case for it start a new thread as a feature request explain the real benifits of making any change and see if there is any support from the users for the change.

[Rob van der Does]

Allow me one last remark: apart from the fact that all the glued-together plugins have all kinds of licenses, the 'collector' also added his own 'license', stating that 'his' plugin is only allowed to run on Dream-H/W. So apart from all the other reasons, that in itself is enough not to bother about such a toy.