> If you can make the visualization easily traversable using simple text queries ...
That's a cool idea. I've been working on something similar, but that takes kind of a different angle which I like. What I have at the moment is a way of specifying filters for which properties should be displayed or not.
Yes, small enough use case... unfortunately the smallest one I can think of is MASSIVE :P
I will document the API and probably open source the client before long. Clients pretty much just send serialized Operation objects as JSON. Operations are like add/remove to/from whatever ___location, using a shared addressing systems for all data structures.
Redis provides data structures to be stored inside its key-value database. It also allows you to setup hooks to listen to whenever something changes. You can potentially use it to connect client/server. Wrappers around client objects will sync with Redis whenever anything changes, and your visualization tool will listen to changes in Redis to update. The advantage with this is that some aspects of your system will benefit from years of testing and thought that went into building Redis.
Oh dang, cool! I will definitely look into that. Want me to send you a message or something if I end up doing it? My email is in the contact section on my webpage.
That's a cool idea. I've been working on something similar, but that takes kind of a different angle which I like. What I have at the moment is a way of specifying filters for which properties should be displayed or not.
Yes, small enough use case... unfortunately the smallest one I can think of is MASSIVE :P
I will document the API and probably open source the client before long. Clients pretty much just send serialized Operation objects as JSON. Operations are like add/remove to/from whatever ___location, using a shared addressing systems for all data structures.