Hi, > Shall I repeat again? The atomspace is already distributed, and there are now > several different ways in which this works. Actually, N ways, to be precise. > I'll describe them below. Again, I invite anyone and everyone to try it, use > it, find out if or how it meets or doesn't meet current needs and > expectations.
Cool, yes def. Vitaly & Alexey and co. (who are leading the Hyperon effort) will check out the current state of the distributed Atomspace code... > Well, I'm hoping that you don't succumb to an urge to rewrite everything from > scratch. I fear that you are tempted to do this. I'm fairly certain I won't > be able to talk you out of it, if that is what you choose to do. We are trying to approach this decision as rationally as we can, via thinking pretty hard about requirements first so we can carefully assess what in the current OC codebase is best rewritten from what isn't There is a Hyperon prototype now which is totally distinct code from current OpenCog, but what relation this prototype ends up having w/ the actual Hyperon system is also currently unclear and up for (not that far) future decision... >> You have seen some of our thinking on Distributed Atomspace, and as I >> recall in our last discussion on this you said you had some critiques >> in mind but didn't offer them in detail. > > > I started reading the document you sent me, but it was full of so many > misconceptions and confusions, it was hard to know how to even start > critiquing it. It was kind of a case of "throw it out and start all over > again". (Oh, the irony) I was (still am) fearful my advice (and any document > I write) would be ignored, so there's not much incentive to work hard on > that. Life is short. Well as you know the distributed-DB aspect is perhaps the part of this on which I'm least knowledgeable... I've been throwing myself more into the Atomese-2 part, both looking at important underlying operations like metagraph chronomorphisms, etc., and experimenting w/ interestingly related languages like Idris (Nil is using Idris 2 for the AI-DSL project, which is distinct from Hyperon though related, and finding it surprisingly performant as well as conceptually powerful...) and formalisms for gradual typing etc. .... Anyway I will make sure that any advice you give, or documents you right, are seriously considered in the Hyperon design process though of course I can't guarantee your views will be concurred with by all (there are others involved e.g. Vitaly who also have vastly more knowledge/experience in the distributed-DB area than I do...) > Perhaps the biggest critique is that a "uuid" is not a central concept, and > that uuids are only needed on communications channels. They don't have to be > "universally unique", they only need to be unique on that channel. This seems an important observation, and (among other points) seems worth remembering in the context of the goal of making a distributed-Atomspace-DB that has "Decentralized control and ownership" in various senses > You might not be aware of the AtomSpace RocksDB StorageNode. I'm aware of it and have seen the work on GitHub, but have never tried it out... (whereas I did actually play w/ the postgres backing store at one point...) > So, for a basic distributed atomspace, each of your friends can run an > AtomSpace on their computers, can trade URL's with one-another, > "cog://example.com" "cog://foo.com/" and "cog://bar.com" and then happily > have all the atomspaces chat with one-another, shipping atoms around > every-which way, running remote pattern matches, etc. > > I suppose you might say that you want something fancier than that... sure! > You'd have to say what that is. (the aforementioned document did not > describe anything fancier than this.) I've got an inkling of possibilities, > but this email is too long already. There are a lot of fancier things we want for Hyperon, but I don't currently have any strong opinion regarding whether building them on top of your RocksDB back-end is a workable approach. Efficient distributed pattern-matching of an appropriately (but not overly) broad class of static pattern-matching queries is the main thing. Some of Alexey's documents linked on that Hyperon wiki page go into what class of static pattern-matching queries is likely most important here. But I've run out of time for typing now, perhaps I will pack that into a later email. thanks ben -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBckTLLa1xJvEFps1rONsbeutpHdj8tLWpVKsHQwNMysBQ%40mail.gmail.com.
