monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] javascript monotone


From: Markus Wanner
Subject: Re: [Monotone-devel] javascript monotone
Date: Tue, 01 Mar 2016 19:27:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0

Hi,

On 03/01/2016 10:16 AM, J Decker wrote:
> This is meant for the architect of the innermost guts of monotone...
> strip away a database, strip away a file system, and just track
> revisions.  track merging of chains....

Huh? What for? And what's your persistence layer, if you strip those?

> I read somewhere that in the distribution of monotone revision chunks
> that there are conglomerated chunks of revision that get sent and can
> later be referenced with a key(?) 

A revision id.

> Maybe that's where the failure is...
> Sorry I've been imagining monotone doing a different job than source
> control, like ledger transactions for bank accounts.  And to share
> those.  The chains of transactions are verifiable, and I guess that's
> what bitcoin is kinda built on.

Yeah, Monotone and Bitcoin certainly share the concept of a
monotonically growing tree. However, Bitcoin doesn't have any kind of
merge functionality and Monotone doesn't need Prove of Work...

> I'd like a system for sharing ID's between nodes in a cluster....
> where IDs are added, sometimes transfer, sometimes don't, those
> clusters exist as a memory idea somewhere in monotone at some point?
> Even if for optimization it is cursor driven so you can only see a
> portion of it at a time.

Cassandra? Tahoe-LAFS? There are many projects with somewhat similar use
cases. I didn't fully (nor partially) understand your use case.

> and something entirely without boost.

Implementation detail.

> Can that be written and shared as a NPM module for node? :)   I hear
> that v8 does extra clever things that allow it to more deeply optimize
> than a static compile does... it could; but it doesn't.

Hearsay. And implementation detail.

(I personally find it hard to believe that JIT can generally be faster
than ahead of time compilation, but...)

> I'd like a VFS interface (virtual file system) interface to monotone
> so I can load a place to store the database?

I thought about that as well. Just out of curiosity: Why would you want
that? And what's the important difference to an ordinary checkout (maybe
to a tmpfs)?

> I dunno maybe it's not so hard?

Given I don't even partly grasp what you're trying to accomplish, it's
hard to say...

Kind Regards

Markus Wanner




reply via email to

[Prev in Thread] Current Thread [Next in Thread]