When you talked about the "database" it come to my mind an Envy Library....maybe something like that would help too. Cheers Mariano On Wed, Feb 24, 2010 at 10:00 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 February 2010 10:09, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
looks like a good master or PhD :) Interesting but need more cycle to think and play with it.
Yes, there's a lot of things to think of. What i imagine is a distributed network of publicly available databases (repositories) where users could easily pick what to load , or update their images without ANY problems using a single mouse click. So, i, for instance could subscribe to Pharo-1.0-stable update stream and to Seaside 3.0-stable update stream. And at any moment i can click 'synchronize' and i'll get the exact match of my code in my own image with code, stored currently in those repos.
Stef
On Feb 24, 2010, at 8:36 AM, Igor Stasenko wrote:
Few more words.
Deltas/packages.
All we need for Delta is to identify the starting point (an image state, from where you started changing it). In contrast to DeltaStreams model, where it tries to capture both an 'old' and 'new' state, so it can be reverted, we don't need it anymore, since we can directly see what was the image state before we applied the changes to it. Having all of the history preserved and tracked is very powerful thing! So, Delta only needs to reference to starting point (URI or some ID, which identifies it, and in case of need can be easily found on the web).
What is cool about it? Suppose, initially, all images started from some release (say Pharo 1.0), so all users sharing the same sources/image state. Now what happens when you start forking or making changes? Users creating a deltas and storing them in the database , and their images now knowing that they are derived from Pharo 1.0 point but also has some changes stored in separate branch or 'fork'.
Now, what happens if user wants to load the changes made by another user: system can easily find the common ancestral point (since all deltas knowing its own ancestral point). And there is two use cases: a) you doing a full synchronization with some remote source. This is useful, when all of us want to use the very same image. This is primarily a good thing for team-based development or Releases(R). b) you doing a partial synchronization (or merge) with remote source. In this case you creating own fork, which derived from , say Pharo 1.0 + some changes from user Foo, Bar, Baz etc and getting own, unique version of image.
So no matter in what way you hacking/mixing the changes, you never lost track of the system history, which means that for any two images which derived from some common ancestral point we could could always automatically generate a diff between them. It means that no matter how far you went in your hacking - others could always load or cherry-pick your code!
Packages? Since model, i describing, operating at lower granularity level (individual changes to methods/classes/doits), which means that any package can be represented as a set of those methods/classes/doits, there should be no problem integrating/interacting at a package level.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project