Re: [Bug][7.4] RuntimePackager incorrectly strips methods

>
>
>> Here here. It'd allow us to build the executable (wouldn't it be nice
>> to link it to an .exe as well [on multiple platforms, not just
>> windows]) from within the image.
>>
> I'm already building fully integrated executables for Windows (.exe) and  
> MacOSX (.app) transparently, incl. icons, custom splash screens,  
> documentation, installers. Anyway, it's still required to restart the  
> "suicide" image once more in order to continue the build process after  
> the stripping.
>
> What I especially don't like is the fact that the deployment procedure  
> itself (incl. ERP product database access) is initially a part of the  
> image to be stripped. This leaves an uncomfortabe feeling of uncertainty  
> about confidential information potentially leaking into the commercial  
> build (apart from footprint issues).
>
> Fine-tuning a runtime image currently remains a tedious trial-and-error  
> thing, because one can't keep the "mother image" up and running while  
> adjusting parameters.
>
> I believe a "write out" solution is clearly superior to any "strip down"  
> or "build up" approach. Imagine you'll instantly get a fully installable  
> product package (or server) from within a full blown development image,  
> simply be the press of a button!
>
> Andre
>

> Charles A. Monteiro wrote:
>> We need a base image (SRE) that basically has just enough to exist and
>> then to load parcels. Terry Raymond worked on something similar but
>> unfortunately what he build only provides for file-in support. I  
>> believe I
>> recall him mentioning that his base image was somewhere in the 2 - 3 mb
>> range.
>
> If Terry's image supports Sockets you could file-in a simple TCP server  
> (or
> client if you wish) that has a read-evaluate loop.
>
> A development image can now be used to connect to the base image and  
> build up
> anything you wish. Perhaps the simplest thing to implement would be  
> copying
> code already present in the host image.
>
>
> R
> -

> Interesting,
>
> another thought also would be that since Terry's base image supports  
> filing in stuff why can't I just file in parcel support :), of course  
> probably easier said that done, I'm guessing that the parcel loading  
> infrastructure is not currently packaged in a way that can just be
> filed  out and filed in ?
>
> I don't have Terry's image so I have not tried. It seems to me that to  
> make his image provide parcel support would be something that could be  
> done a lot quicker and therefore provide relief upfront while we wait
> for  something like the "ImageWriter".
>
> -Charles
> On Thu, 23 Feb 2006 12:02:28 -0500, Reinout Heeck <[hidden email]> wrote:
>
>> Charles A. Monteiro wrote:
>>
>>> We need a base image (SRE) that basically has just enough to exist and
>>> then to load parcels. Terry Raymond worked on something similar but
>>> unfortunately what he build only provides for file-in support. I  
>>> believe I
>>> recall him mentioning that his base image was somewhere in the 2 - 3 mb
>>> range.
>>
>>
>> If Terry's image supports Sockets you could file-in a simple TCP
>> server  (or
>> client if you wish) that has a read-evaluate loop.
>>
>> A development image can now be used to connect to the base image and  
>> build up
>> anything you wish. Perhaps the simplest thing to implement would be  
>> copying
>> code already present in the host image.
>>
>>
>> R
>> -
>
>
>
>

> Here is another crazy idea:
>
> How difficult it is to make RTP to file out all of the code from the  
> system it marks to keep ?
>
> RTP does reasonable enough job of tracing all the references statically,  
> and monitoring them dynamically as well.
>
> So if we can make RTP to file out all of the application specific code,  
>   and the file it into the Terry's image,  we can automate the above  
> procedure.
>
> Here is another thought - in early days of VW before RTP it was much  
> simpler image stripper, I wonder if it still exist somewhere.  It could  
> be used to strip the Terry's image ...
>
> My 2C.
>
> --Mark
>
> Charles A. Monteiro wrote:
>
>> Interesting,
>>  another thought also would be that since Terry's base image supports  
>> filing in stuff why can't I just file in parcel support :), of course  
>> probably easier said that done, I'm guessing that the parcel loading  
>> infrastructure is not currently packaged in a way that can just be  
>> filed  out and filed in ?
>>  I don't have Terry's image so I have not tried. It seems to me that  
>> to  make his image provide parcel support would be something that could  
>> be  done a lot quicker and therefore provide relief upfront while we  
>> wait for  something like the "ImageWriter".
>>  -Charles
>> On Thu, 23 Feb 2006 12:02:28 -0500, Reinout Heeck <[hidden email]>  
>> wrote:
>>
>>> Charles A. Monteiro wrote:
>>>
>>>> We need a base image (SRE) that basically has just enough to exist and
>>>> then to load parcels. Terry Raymond worked on something similar but
>>>> unfortunately what he build only provides for file-in support. I  
>>>> believe I
>>>> recall him mentioning that his base image was somewhere in the 2 - 3  
>>>> mb
>>>> range.
>>>
>>>
>>> If Terry's image supports Sockets you could file-in a simple TCP  
>>> server  (or
>>> client if you wish) that has a read-evaluate loop.
>>>
>>> A development image can now be used to connect to the base image and  
>>> build up
>>> anything you wish. Perhaps the simplest thing to implement would be  
>>> copying
>>> code already present in the host image.
>>>
>>>
>>> R
>>> -
>>

> -----Original Message-----
> From: Reinout Heeck [mailto:[hidden email]]
> Sent: Thursday, February 23, 2006 12:02 PM
> To: [hidden email]
> Subject: Re: [Bug][7.4] RuntimePackager incorrectly strips methods
>
> Charles A. Monteiro wrote:
> > We need a base image (SRE) that basically has just enough to exist and
> > then to load parcels. Terry Raymond worked on something similar but
> > unfortunately what he build only provides for file-in support. I believe
> I
> > recall him mentioning that his base image was somewhere in the 2 - 3 mb
> > range.
>
> If Terry's image supports Sockets you could file-in a simple TCP server
> (or
> client if you wish) that has a read-evaluate loop.
>
> A development image can now be used to connect to the base image and build
> up
> anything you wish. Perhaps the simplest thing to implement would be
> copying
> code already present in the host image.
>
>
> R
> -

> On 24/02/06, Charles A. Monteiro <[hidden email]> wrote:
>> but my problem is that I do want to load runtime components i.e. parcels
>> at runtime but want as minimal a base image as possible,
>
> Right on, Charles.
>
> I think this is the single most important requirement for making
> VisualWorks deployment sane.  Currently it's like a video game - you
> play for a while (strip an image) die (the image crashes because
> something is wrong with the strip) learn from your mistake and play
> again.  Repeat.  It is impossible to be certain in this environment.
>
> I would like to see a minimal image that can:
> a) load a parcel
> b) produce a comprehensive stack dump in a known location if things go  
> wrong
>
> Given these two, any image can be constructed.  Even one from which
> you can play the stripping game if that is your preference.
>
> And "minimal" is not about size primarily (though that is a useful
> thing in itself) it is about have the fewest possible things in the
> image that could go wrong, and knowing *exactly* what is in that base
> image and why.
>
> IMO this should to be a high priority project for Cincom.
>
> All the best,
>     Bruce
> --
> Make the most of your skills - with OpenSkills
> http://www.openskills.org/

> -Charles
>
>
> On Thu, 23 Feb 2006 15:29:10 -0500, Bruce Badger <[hidden email]>
> wrote:
>
> > On 24/02/06, Charles A. Monteiro <[hidden email]> wrote:
> >> but my problem is that I do want to load runtime components i.e.
> parcels
> >> at runtime but want as minimal a base image as possible,
> >
> > Right on, Charles.
> >
> > I think this is the single most important requirement for making
> > VisualWorks deployment sane.  Currently it's like a video game - you
> > play for a while (strip an image) die (the image crashes because
> > something is wrong with the strip) learn from your mistake and play
> > again.  Repeat.  It is impossible to be certain in this environment.
> >
> > I would like to see a minimal image that can:
> > a) load a parcel
> > b) produce a comprehensive stack dump in a known location if things go
> > wrong
> >
> > Given these two, any image can be constructed.  Even one from which
> > you can play the stripping game if that is your preference.
> >
> > And "minimal" is not about size primarily (though that is a useful
> > thing in itself) it is about have the fewest possible things in the
> > image that could go wrong, and knowing *exactly* what is in that base
> > image and why.
> >
> > IMO this should to be a high priority project for Cincom.
> >
> > All the best,
> >     Bruce
> > --
> > Make the most of your skills - with OpenSkills
> > http://www.openskills.org/
>
>
>
> --
> Charles A. Monteiro