Hi Guillermo,
On Sat, Jun 28, 2014 at 11:07 PM, Guillermo Polito < [email protected]> wrote: > With Martin we started on friday to sketch a kind of resource manager with > an internal file system. Our idea is to plug a resource manager to each > package and then serialize a fuel file of it inside the mc package. > I like the idea of a file system, but don't like the idea of an internal file system. The issue here is that I will probably want to use external tools to create the external data, and will want to export the external data from Monticello to an external file system when I come to deploy (that's the point right?). So the issue is how to provide a nice interface to determining which external files are part of a package and in including them in the externalization of a Monticello package (e.g. the zip format of an mcz would seem to be adequate). 2¢ > But we just started it... > Good luck! The one glaring hole in all the Smalltalk versioning systems I've seen so far is the lack of support for external data. I hope you succeed!! > On Sun, Jun 29, 2014 at 5:22 AM, Sean P. DeNigris <[email protected]> > wrote: > >> How do we do this now with MC? Are there options other than "encode in >> string >> returned by method" like I've seen done for image data? >> >> My use case is that I have a very static domain, and so doesn't require >> user >> changes. I think the easiest way to distribute it would be to edit the >> data >> on a dev image, and then somehow save the data in a way that can be >> committed with MC so that loading via MetaC config loads the latest >> version >> of the data. What would be the best way to do that? >> >> Thanks. >> >> p.s. on a related note, I'm also interested in distributing static files >> with the code e.g. maybe a PDF readme >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Sharing-Versioning-Data-tp4765528.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > -- best, Eliot
