[squeak-dev] Re: Ubuntu package maintainers help

Matej Kosik kosik at fiit.stuba.sk
Thu Apr 23 11:04:22 UTC 2009


Jerome Peace wrote:
> 
> HI Matej,
> 
> Thanks for your reply.
> 
> --- On Thu, 4/23/09, Matej Kosik <kosik at fiit.stuba.sk> wrote:
> 
>> From: Matej Kosik <kosik at fiit.stuba.sk>
>> Subject: Re: [squeak-dev] Re: Ubuntu package maintainers help
>> To: peace_the_dreamer at yahoo.com, "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
>> Date: Thursday, April 23, 2009, 1:38 AM
>> Hi all,
>>
>> Jerome Peace wrote:
>>> [squeak-dev] Re: Ubuntu package maintainers help
>>>
>>> Hi Matej,
>>>
>>> Looking at your dependency chart I see that there is
>> now a language clash.
>>> We need to disambiguate what is meant by
>> squeak-plugin.
>>> The word plugin is used to mean both 
>>> sqeuak-browser-plugin which is a dingus that adds
>> functionality to an external browser. 
>>>
>>>
>>> and 
>>> squeak-internal-plugins which are pieces that add
>> functionality or speed to squeak itself.
>>> those plugins are 
>>> things like vm-sound-ALSA which when missing caused
>> the sound problem on Ubuntu.
>>> Most of the time those plugins are in a default path
>> and there is no need to mention them.
>>> For etoys the default path plugins are in the same
>> place as the vm itself.
>>> For the ubuntu squeak the plugins are in a separate
>> directory than the vm and the shell just happens to know
>> where that is.
>>> To add to the merry confusion. There are vmplugins to
>> make the squeak-browser-plugin work. These are in the
>> vmplugin directory with and np... prefix.
>>> On Ubuntu the sqeuak-plugin package is considered
>> different than the squeak package.
>>> The squeak-plugin package may also refer to a
>> particular image. Maybe there is something special a squeak
>> needs to do if being run in a browser.
>>> Murkier and murkier.
>>>
>>> =====
>>> Howerer when I am trying to describe a problem that
>> concerns them the other meaning of the word plugin confuses
>> things a lot.
>>> So we need to find and use a consistent language that
>> allows us to distinguish between the browser plugin and a vm
>> extention plugin. Particularly for the benifit of external
>> packagers.
>>> Jose: how do you deal with this? How do we
>> disambiguate the two meanings?
>>> Yours in curiosity and service, --Jerome Peace
>> The package with the name `squeak-plugin' in my case
>> means the
>> web-brower plugin. Its meaning is disambiguated on two
>> places:
>> - the package description itself states that it is a
>> web-browser plugin
>> - the wiki page:
>>   http://wiki.squeak.org/squeak/3616
>>   also states that.
>> So, I hoped that users have enough information to determine
>> what
>> services this package offers.
>>
>> Developers (who know also that there are internal and
>> external plugins),
>> I hope, will have even less problems to disambiguate.
>>
>> If my assumptions are wrong, the package name can be
>> changed.
>>
>> I do not see this as a major problem.
> 
> It is easy to see what is understandable to you is understandable to another. Even when from the others viewpoint this is not true.

I can change the package name from `squeak-plugin' to
`squeak-web-browser-plugin'. OK?

I haven't done this yet. I am looking forward to hear from Jose
regarding the merging process. That's critical.

> Packagers are somewhat outsiders. It is our duty to be very careful with our language about things we want them to understand.
> 
> In particular we will have to mention the difference between the vm, the vmplugins and the various things they do to extend the power of the vm. This miscommunication is the meta-problem of sound being lost on squeak images and the bug not being fixed for over a year even though all that is needed is copying one file into the vmplugin directory.

I agree. I have added these suggestions to the TODO list.

> 
> How does the squeak-plugin image differ from the other squeak images?
> Can any squeak image be nominated for plugin duty or is there
> something that the image has to know how to handle?

I view it as some sort of standards to which people can rely to when
they embed Squeak projects (*.pr files) into web-pages via
<EMBED>...</EMBED> tags. Obviously, no project works in any image.
Projects that are supposed to work with Squeak plugin has to be tested
with a specific image and squeak-plugin-image is that image.

In theory, any image could be used with squeak-plugin but it would
create a chaos. Creators of projects would not know to what properties
of the image they can rely.

> Like say a command line passed from the browser to the image?
> How can we test images to see if they can be browser plugin images as well?

If you figure out, where `squeak-plugin-image' package installs
/usr/share/squeak/SqueakPlugin.image.gz
the image, you can replace it with your own and see what happens.

I think, once I have tried to do it, I think.

> 
> Also as I was looking at the vmplugins it looked like for each supported browser we had a np<browser name>Plugin.
> There was a link to the appropriate plugin from the firefox browser on my Ubuntu. So I presume each brower would need to be hooked up like that.

I haven't seen such VM plugins.

> 
> Can you help clarify this for me?
> 
> 
> 
> 
>> Major problem is, if
>> we agree with
>> Jose on merging of our separate forks of packages. If we
>> merge them, we
>> can also concentrate on things we are interested in (he is
>> interested in
>> Etoys, we are interested to a rich set of images) and we
>> can share work
>> that we have in common---maintenance of the squeak-vm
>> package.
> 
> Cool.
> 
> My part in this is to get a simple solution in place so sound is in Ubuntu's current vm distribution ASAP. 
> Then push to get the website set up to reflect my Aladdin story.
> 
> Which is one of the reasons I am pushing for extra care to be taken with the descriptive language. 
> 
> Yours in curiosity and service, --Jerome Peace
> 
> 
> 
>       
> 




More information about the Squeak-dev mailing list