On Tue, May 15, 2012 at 4:51 PM, Yanni Chiu <[email protected]> wrote:
> On 15/05/12 3:21 AM, Pavel Krivanek wrote: > >> >> The resultant image is not production-ready because Fuel Package >> Loader currently doesn't work with changes file. >> > > What does this mean? Is Fuel Package Loader supposed to append > corresponding source to the changes file, when compiled methods are loaded > via fuel? Shouldn't that be optional? > > Hi. First, let me say that FuelPackageLoader is just a baby borning. Nothing is decied completly yet. So far, the best design we have in mind is: 1) The user can export/import packages without source code. This serialization goes into a file. Say we call it yourPackage.fuel. The application can be run, deployed, and even browse decompiled code. Nothing go to .changes. 2) The user has ANOTHER possibility to ALSO serialize source code. That does not mean just source code but also timestamp, class commetns, etc. Then during import, we should do kind of waht monticello does: include source code in the system (.changes or whatever). This would be in a differnt file (also serialized with fuel, and also being a binary fuel) called it for example, yourPackage.source So you can distribute your app with or without source code. Well, that's the plans at least we have with Martin so far. 1) is working quite well (but still there are work to do). 2) is not even started (and that's why Martin is in GSoC). is this clear? This setup reminds me of .SLL files used in VSE (Visual Smalltalk > Enterprise). You could start with a "frozen" base image, and on startup, > load all your application code through .SLL "library units". (I can't > remember whether or not you could dynamically link/unlink the .SLL > packages; I think you could.) > > I don't know such details but indeed it looks similar. Cheers -- Mariano http://marianopeck.wordpress.com
