Ah, interesting. I was looking at the theme icons yesterday and importing/exporting those would benefit from this view on resources.
Also, there is the Seaside WAFileLibrary which provides some support on that front, allowing one to do a #deployFiles and get them out and also there is the support for getting them in. There is no Fuel file there. For Fuel, the main pain point is when there is an upgrade of Fuel (somewhat unexpected to the user) that renders the existing files unreadable. I had that on a StartUp and it made things weird... Not sure we want to use Fuel then. Phil On Wed, Jul 2, 2014 at 2:44 AM, Eliot Miranda <eliot.mira...@gmail.com> wrote: > Hi Guillermo, > > > On Sat, Jun 28, 2014 at 11:07 PM, Guillermo Polito < > guillermopol...@gmail.com> 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 <s...@clipperadams.com> >> 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 >
