2009/8/16 Göran Krampe <goran at krampe.se>:
> 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.