Finally finished the majority of ResGate’s client code, just need to polish it up and make cover some edge cases.
But, I did make a cool cache visualizer that I thought might be interesting:
I can see why Acci decided to make resgate, the server really does send a lot of info to you >w<
edit:
there are like 50 more RID’s below what you can see x
ha, I have the same but done in dart: I visualize the models as yaml documents and make rid hyperlinking work 
Nice, sounds like a better way of doing it, for this you have to manually find the connected data >w< I might make a better system in pygame sometime, but for now this is more than enough to debug any errors that could occur.
What app/site is that code on?
Neat, Ico!
But I honestly didn’t make Resgate for the purpose of Wolfery/Mucklet.
It was rather the opposite; I started making Wolfery as a test case of sorts in order to really try out Resgate.
Turns out Resgate performs pretty well in most cases 
Too bad it was developed by a single developer instead of some big dragon like Google or Facebook. But I am still rather pleased with it, and it makes an application like this rather pleasant to build.
Too bad it was developed by a single developer instead of some big dragon like Google or Facebook. But I am still rather pleased with it, and it makes an application like this rather pleasant to build.
gRPC and GraphQL exist. Of course, they solve a set of problems that’s very different from Resgate, but, at the same time, they aren’t prone to the problems Resgate has
It’s still a very interesting algorithm, it’s sure fun to poke at low-level res’s syncing primitives.
True. But while they do have some overlapping properties and problems they try to solve, they have very different approaches. But I never got too friendly with any of those two. I don’t know why really. It was just… well… Ah, not sure.
Not sure which group of problems you refer to, but yeah - real time updates does tend to come with its set of issues . And then we have the eco system! Phew. Can’t beat them at that!
Comparing the streaming versions of gRPC and GraphQL to Resgate, the thing you notice is that the former two have a much simpler synchronization between the backend and the client. Effectively, it’s trivial to stream updates (and very contextual updates for graphql) onto the client, while Res requires you to carefully manage the tracked state. It’s not bad, it’s just not that straightforward (I’m looking at you, weak references!)
Res does much more for multiple backends, that’s true, but it comes with more complexity tradeoffs. Off the top of my head, the librarian bot desyncs on every server upgrade you do. It just stops receiving the massages. Why? shrug. Can it reconnect and keep up? Absolutely. But with e.g. a streaming grpc that wouldn’t have been an issue as much because it’s just… well… RPC. It can be easily dumbed down to primitives, while it might be impossible to trace the propagation of data updates from backends to customers in Res given how implicit they are.
But again, I might be looking at this more from the protocol implementor POV rather than end user. Having to implement gRPC (although it’s not that bad given it’s just protobufs over http2), and res, I’d surely prefer to implement the former.
It’s on Vs code. All though others may be using others like sublime text or vim.
Oh! Yes. In that case; absolutely.
The RES client protocol is much more complex to implement. gRPC is mostly an RPC with streaming support. Pretty straight forward. But the RES client protocol, on top of its own RPC, also has the whole concept of resources and how to update them with events, and how to synchronize them without access to the event stream, and so on.
Actually, early on I considered using gRPC as the RPC for RES client protocol… but scrapped it due to protobuf’s data not being self-describing, requiring a schema, which was not compatible with Resgate’s requirements.
Resgate is meant to be simple to work with if you have a client. But to create the RES client yourself? No, that is not simple 
Yeah, I have a separate part to the code that handles all the resgate stuff, I tried to keep it as its own module as best as I can.
It is initialised under the app and then the bot (which is also initialised under the app) will have access to it. (Sound like a familiar setup? I took a bit of advice from this really good Roleplaying site ^w^)
I am slowly getting a simple version of it up and running from the res client protocol docs on the GitHub page bu I am not 100% sure if that covers everything?
That is odd.
Actually, that is really odd.
My server upgrades should not affect the bots at all, since they should never even be disconnected.
Most of the times (like, every update for the past 6 months), I only update the services and leave Resgate running.
The only way a client/bot should be able to tell an upgrade has taken place is by it possibly getting a few more change-events that adds new properties to some models.
If it happens again, please tell!
Actually, that is really odd.
It might be on me, then 
after all:
to create the RES client yourself? No, that is not simple
and I’m running a home-brewn stack.
Want a funny joke? The scambanker bot will get into a client-side desync (getting an update for a model it’s not watching) but only if it runs without logging. There’s 100% chance of my missing some async corner case somewhere (and that’s why I want to switch over to rust that just doesn’t allow you to have those problems at a compiler level).
To cover 100% of the RES client protocol is tricky. The protocol only defines the communication, but it does not go into implementation details on how to handle reconnects, or how to discern if a resource is considered subscribed (directly or indirectly) or not.
But to get the basics is still doable!
Only when NOT logging? Painful!
Yeah, but how to solve Rusts borrowing with Resgate that may update models/collections at any time?
I don’t know enough about Rust to be able to tell for sure, but I think I would consider working with unmutable models/collections that are just copies made from the cache, instead of passing around a single shared instance.
think I would consider working with unmutable models/collections that are just copies made from the cache, instead of passing around a single shared instance.
That’s exactly what I settled on. If you request a model from the client, you get an immutable copy that’s yours to own and do whatever you see fit. It’s more resource-heavy but it’s like an optocoupler between the drifting state and what your business logic works with.
Yeah, I had the same issue with the last updated on mine.
Hmm.
The only logical conclusion would be that the bug is in the code of the core service, that somehow messes up the state of bot-controlled characters during the bootup phase. Probably more precise when it tries to fetch a list of controlled characters, to start the auto-sleep timers.
I’ll look into it!
