Onex & ValOS interoperability thoughts and stu...
# of-end-user-programming
i
Onex & ValOS interoperability thoughts and stuff
d
😄
i
😛
d
OK - what's your resource model? If there's a low "impedance mismatch", then that could work.. My objects have "handles" (UUIDs) like URLs, but unlike web resources are dynamic and notify changes across a P2P network. Ilari Kajaste [10:10] Because even though our current IDE is a very standard-looking "treeview & code editor" our grand plan is to have many different interfaces for manipulating the code structure.
i
So the ValOS resource model consists of Resources, which have a specific URI. These are Entities, Relations or Medias. The basic example is an Entity which contains some Properties. Any changes to either Entities or their Properties are automatically transferred to any subscribed clients, and listenable by code.
d
same kinda thing then
i
The change propagation does not (currently, at least) use P2P network, but instead some Authority owns any Resource, and the Authority handles the data transfers.
d
ok. well I'm re-implementing all of my Java version in C, and I haven't got far with my P2P networking in C yet
so I can learn the lessons of the Java version
i
But the code running on top of the system doesn't care about where the Resources are, or how changes are transferred - they're all the same to the code.
d
right
in Onex you don't know if a resource is remote, but do have to bear in mind that networks fail so you need timeouts sometimes
i
The basic model for handling data consistency in ValOS (currently) is that when something changes, the Gateway (client) makes the change to its own model, then sends that change to the Authority. Once the Authority responds with an "ok" then the Gateway will mark that change as a Truth. If the Authority responds with a failure the Gateway will remove the change. Depending on the type of failure, the Gateway might then retry, or just leave the state unchanged.
If there's a data connection problem, the Gateway will store the changes in a queue and work as-if connected, and once the connection is restored it'll send all the changed to the Authority.
d
ok .. Onex is much more relaxed than that!
Onex has a best effort and could fail philosophy, the lowest level of reliability, since you need to cater for cases where you actually don't care if data is updated in a timely way
then build reliability on top, using timeouts, at the user programming level
i
If the Authority has in the meantime already received other changes, then it'll just reject, and the Gateway will fetch the latest changes and reapply its own things on top of the latest changes (unless there are conflicts).
Yeah, ValOS is very strong on keeping consistency.
d
In Onex, being P2P is deep in the architecture, so any object is the Authority for itself
no conflicts are possible
So looks like there's "impedance mismatch"! 😄
i
Yeah, we do have thoughts about having Resources in P2P "Authorities" too, but they're the future.
Hmm. What do you mean by all objects being an authority though? Like, if two clients want to make a change to the same object, what happens?
d
that's not allowed. an object is the sole master of its own destiny!
only it can change itself
i
But something configures the object, though?
d
objects are "animated" by local execution of declarative rules
i
So basically you define a ruleset for the object with the spreadsheet-style interface, and then animate the object to use it?
d
yes, but the object is "animated" by the rules. change the rules and its behaviour instantly changes accordingly
i
How do you change the rules of the object?
d
in the UI
but you already said that above .. so .. ?
i
Right, so you can change the rules, but not the properties of the object itself?
d
no you can edit them too
I admit I sometimes get confused about changing the rules over a property and the property itself!
but that's a UX issue
i
So then there can be two clients setting a same property for it at the same time?
d
"clients"?
i
Two things running the UI to change it, I guess?
d
well if the object is hosted/lives in your Android phone, then you can do the changes directly. if it's on a server, you have to send it rules to execute to update itself, if it allows you to do that
so it looks like you're editing it, but it's getting change "suggestions" in the form of one-off rules
it's still up to the object if it applies the rules though
i
Right.
d
so, yes, in principle you could have "conflict"
but it's up to the object to sort that out with its own rules, if that's necessary
I've never had an issue though, with that kind of complexity
just last-one-wins editing
i
Then indeed a similar concept in a ValOS model would be an Authority that has a single root object, and that also runs the code on it.
d
if you wanted more strict conflict resolution, you'd not use these one-off update rules
Authority that has a single root object, and that also runs the code on it.
OK
i
Right now our Authorities don't really run the code of the things they contain, but that's not at all beyond the scope of our model.
d
well it sounds like you've got the Minecraft problem
a client thinks one thing, but the server has to be allowed to push back
which is a bit jarring in the UI when it happens
😄
i
Yup.
d
in Onex, each thing is its own authority, so the "land" would be on one peer, the "player" and their stuff on another, and everything just propagates with best efforts
(so you have to still build in non-cheating rules)
notification happens by (a) polling and (b) pushing
if pushing fails, polling makes up later
i
Yeah, there's definitely interesting cases in the P2P resource model.
And indeed the ValOS architechture itself does support it as one case, since the Resource don't really care where they live.
But yeah, we don't have anything like that implemented right now.
However, it might be possible to have an interoperable interface in the way that an gateway could read and (try to) manipulate a Onex object data.
So basically when you read from one of our current authorities you get the data as you do, and any changes you make are sent to the Authority. But when you read from Onex object it fetches its data, and making any changes sends (or attempts to send) the changes to that Object.
If there would be an interface for doing that, then as long as the Onex objects have a UUID they could be directly referenced by other ValOS resources.
Anyway, mostly food for thought, it doesn't seem like it has any applicable cases anyway, the model seems different enough.
But we are interested in interoperability.
There's also another layer of interoperability - the ruleset model. It would be possible to use ValOS resource model for building the Onex ruleset (the stuff in the spreadsheets) and then send that to the Object (as converted into the Onex format). Not sure what the use would be since you already have a ruleset designer, but could be an interesting experiment at some point.
And it would be possible to also build an valos engine that runs the Onex model being designed on valos, to do virtual testing, preview and stuff like that. But again, why not just run the Onex model directly, so yeah.
Anyway, interesting discussion. 🙂
d
sorry .. had to do something
✔️ 1
I think if a couple of us are actually successful in our projects, that interop will obviously be important
but that's going to come later
i
yup
d
I've got a whole Java->C job to do first!!
i
Happy converting 🙂
d
🙄 wish I'd started in C
i
Well, everything worthwhile has been rewritten at least once. 😛
💯 1
d
I've written and rewritten in: C, C++, Java, Ruby, Python, Javascript/Node 😄
i
😄
d
Better than interop would be "How we handle architectural issue X", where X is: - the above discussion on authority/conflict - how you do null/undefined/unknown - whether state is actually as evil as they say - how to make the UI as fluid and autocompletey as poss
..etc
i
Yeah, the UI/UX issue is something I'm personally most interested in.
d
I have Minecraft's fluidity as one of my standards to aspire to. It's so satisfying to build stuff. Maybe we need sound effects?!
i
😄
Of course the whole of UX does include the architechtual decisions.
d
actually that may not be joking .. phones have sound effects for camera and unlock
i
Yeah, you're not wrong.
d
imagine a "phldmmm!" sound when you create a new object
😄
i
Sadly, a sharp focus on UI kind of still on a backburner for us. 😐
d
well that's a shame
i
It's definitely a thing we'll be looking into, but right now we need focus more on other stuff. So I mostly try to do whatever fits into part of the overall process.
👍 1
The architechtoral components of the UX are in focus though. One of the major points of valos is to make it as easy and natural as possible to create something worthwhile.
It's just that the UI for actually doing that doesn't really highlight that yet.
And the point is not to make the IDE do a lot of the necessary work for you, but to have an architecture that makes defining worthwhile applications easy.
So yeah, that falls into the UX sphere.
(DX, really)
d
right