[squeak-dev] Re: Ubuntu package maintainers help

> [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

> From: Matej Kosik <[hidden email]>
> Subject: Re: [squeak-dev] Re: Ubuntu package maintainers help
> To: [hidden email], "The general-purpose Squeak developers list" <[hidden email]>
> 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.

> 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.

>
> HI Matej,
>
> Thanks for your reply.
>
> --- On Thu, 4/23/09, Matej Kosik <[hidden email]> wrote:
>
>> From: Matej Kosik <[hidden email]>
>> Subject: Re: [squeak-dev] Re: Ubuntu package maintainers help
>> To: [hidden email], "The general-purpose Squeak developers list" <[hidden email]>
>> 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.

>
> 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
>
>
>
>      
>

>
> > 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

>>> 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.
>>
> Umm. Ok. So the web-plugin image has a sort of contract with the .pr  
> files that want to be run in it.
>
> Is there any reason why we wish a squeak image for a  web-plugin?  
> Rather than an Etoys-image for the web-plugin. I ask this because  
> Squeakland seems to me to be the only one right now persuing this.
> AFAIK they have cornered the market.
>
> I seriously doubt the either the 3.9/3.10 branch wants to pursue  
> maintaining this.
> Ditto for the Pharo branch.
>
> Bert: Any insight into this point?
>
>> 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.
>>

> From: Matej Kosik <[hidden email]>
> Subject: Re: [squeak-dev] Re: Ubuntu package maintainers help
> To: [hidden email]
> Date: Thursday, April 23, 2009, 5:12 PM
> Jerome Peace wrote:
> > Umm. Ok. So the web-plugin image has a sort of
> contract with the .pr files that want to be run in it.
> >
> > Is there any reason why we wish a squeak image for a
> web-plugin? Rather than an Etoys-image for the web-plugin. I
> ask this because Squeakland seems to me to be the only one
> right now persuing this.
> > AFAIK they have cornered the market.
>
> The squeak-plugin-inmage (Debian package) brings in
> squeakland image. I
> think that is OK.
>
> Rarely, when I did some fancy things, they were working in
> ordinary
> Squeak images (3.8, 3.9) but they did not work in
> squeakland image. One
> must count with that when he creates pr projects for the
> web.
>
> Ideally, those *.pr files are authored directly in the
> squeakland image.
>

> >
> > Bert: Any insight into this point?
> >
> >> 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.
> >>
> > It has been easier for me to create launchers to
> redirect
> > the pieces. That way I don't have to deal with
> special permissions. Everything can be in a local directory.
> >
> > My user story on this: Doing a save as in squeak on
> Ubuntu sould also create an instance of a desktop launcher
> for that image. I.E. Squeak should be Ubuntu aware on
> Ubuntu. But that as the say is another story. (And my next
> mantis issue.)
> >
> >  
> >>> 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?
> > When I installed Etoys amoung the things in the vm
> directory were
> >
> > /usr/share/Etoys.app/Contents/Linux686/npetoys.so
> > /usr/share/Etoys.app/Contents/Linux686/npetoysregister
> > /usr/share/Etoys.app/Contents/Linux686/npetoysrun
> >
> > and a link
> > /usr/lib/firefox/plugins/npetoys.so
> > pointing to
> > /usr/share/Etoys.app/Contents/Linux686/npetoys.so
> >
> > in the firefox directory.
> > I am presuming that is what links the browser to
> > its helper in this case the Etoys image and stuff.
> >
> > Jose would know more.
>
> (a guess)
>
> The np* prefix indicates that it is a "Netscape
> Plugin". Like
> `npsqueak.so' we provide. Bert Freudenberg wrote it.
> What is different
> in etoys web-browser plugin I have no clue.
>
> The npetoys.so is not "VM plugin".