Smalltalk › Squeak › Squeak - Dev

[squeak-dev] Our process, some loose ideas regarding DS + MC

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

23 messages Options

Göran Krampe

Re: [squeak-dev] Re: Our process, some loose ideas regarding DS + MC

Ralph Johnson wrote:
> Göran Krampe explained how DS gets loaded into two phases. First, the
> Delta gets read from a file and turnd into an object in the image, but
> no classes are changed. Second, the Delta is applied, i.e. it changes
> the classes.

Exactly. And the "apply" operation is performed by a visitor, by default
one that uses SystemEditor. So the domain model could be reused/ported
to a totally different Smalltalk. I think this is an ever more
interesting aspect - we have lots of Smalltalks these days :)

> Is DS going to replace .source and .changes? I did not think it was.

It is not meant to - but I do think Matthew for example have noticed the
fact that it could be used to do that. I have not examined that area.

> I thought it was competing more directly with .cs files and, to a
> certain extent, with Monticello.

Yes.

> Thus, if you only want to load a
> program and run it, you won't need to keep the Deltas around once you
> have applied them.

Right.

regards, Göran

Igor Stasenko

Re: [squeak-dev] Re: Our process, some loose ideas regarding DS + MC

2009/8/16 Göran Krampe <[hidden email]>:

> Ralph Johnson wrote:
>>
>> Göran Krampe explained how DS gets loaded into two phases. First, the
>> Delta gets read from a file and turnd into an object in the image, but
>> no classes are changed. Second, the Delta is applied, i.e. it changes
>> the classes.
>
> Exactly. And the "apply" operation is performed by a visitor, by default one
> that uses SystemEditor. So the domain model could be reused/ported to a
> totally different Smalltalk. I think this is an ever more interesting aspect
> - we have lots of Smalltalks these days :)
>
>> Is DS going to replace .source and .changes? I did not think it was.
>
> It is not meant to - but I do think Matthew for example have noticed the
> fact that it could be used to do that. I have not examined that area.
>
>> I thought it was competing more directly with .cs files and, to a
>> certain extent, with Monticello.
>
> Yes.
>

Right, but what is .changes if not a one, huge .cs?
Only .source could be viewed differently, because there cannot be
something 'before' them.

>> Thus, if you only want to load a
>> program and run it, you won't need to keep the Deltas around once you
>> have applied them.
>
> Right.
>
> regards, Göran
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko

Re: [squeak-dev] Re: Our process, some loose ideas regarding DS + MC

In reply to this post by Göran Krampe

2009/8/16 Göran Krampe <[hidden email]>:

> Igor Stasenko wrote:
>>
>> I am well aware about Tirade, other readers may not, of course. :)
>
> Exactly. :)
>
>> I have nothing against one or another data format. If it designed well
>> to serve its purpose - no-one would put you on fire for that. :)
>> My concern is different - the ability to 'offload' the bulk data from
>> image to persistent storage and be able to reload it
>> back in case of need.
>> This is what .source & .changes files serving for with more or less
>> success.
>> So, in this respect, do you see how we could improve the state of
>> affairs , taking in account my proposal, that
>> lets call it a 'hibernated' Delta (one which offloaded data from image
>> to some storage) could carry a pointer to resource which holding all
>> the information which needed to 'unhibernate' it. URI/URL mechanism..
>
> That idea seems like a good idea, a "smart stub" you mean? Should be nice to
> have yes.
>

Stub, 'remote delta', 'cached delta'.. whatever..

The idea is, to let user to choose a different ways how/where to
persist deltas,
and use a uniform mechanism to locate/access them from the very starting.

It should seamlessly give a way to use deltas on centralized or
decentralized , local storage
on files / databases.. And give us a way to plug-in any other kind of
of data access without problems, in future.

Remember , we disscussed the P2P ways to distribute delta streams? it
fits nice with the above.

>> Same, btw, as Monticello doing with different repositories i.e.
>> MCHttpRepository
>> location: 'http://www.squeaksource.com/DeltaStreams'
>> user: ''
>> password: ''
>>
>>> A Delta is handled in two steps: First you load it. This just means
>>> deserializing it from Tirade into an object. Then you apply it. This is
>>> the
>>> step that affects the image, atomically, using SystemEditor.
>>>
>>>> But i think its too early to think about it.
>>>> Or.. why too early?
>>>
>>> Not too early at all, in fact almost too late. :)
>>>
>> its never too late to improve things :) But can you explain what you
>> have in mind?
>
> I think we misunderstood each other, there is nothing done yet in the area
> you describe, so not too late there. I was referring to domain model and
> Tirade.
>

Okay.

>>>> You already mentioned different ways to persist the deltas.. so
>>>> a delta 'pointer' could be represented by a tuple: (adaptor , id)
>>>>
>>>> where adaptor could be: file, couch DB, url or anything else,
>>>> and id is an additional info , identifying given delta.
>>>>
>>>> Or, just use a common denominator of all of this stuff - URI.
>>>> I don't think that its hard to introduce a new URI, which identifies a
>>>> Couch DB storage :)
>>>
>>> The CouchDB API is purely HTTP restful. Each document in CouchDB is
>>> accessed
>>> simply by a URL. Fits nicely in this area.
>>>
>> Perfect.
>
> Yes.
>
> regards. Göran
>
>
>

--
Best regards,
Igor Stasenko AKA sig.