Conversation:
Notices
-
@verius If I'm not mistaken that's how StatusNet handled it prior to ActivityVerbs (ie a very long time ago indeed)
-
@verius What I want to do regarding APIs in postActiv, is have them be modular so we can pull them in and out easily. If we do this, we could easily have an endpoint just for custard, that's tailor made to feed it data in the way we desire of it.
-
@verius This is kind of already doable with creating new endpoints on the router, I just want to add some stuff to make the abstraction of this easier and the organization more obvious. Right now the router is for everything and has no namespacing at all so trying to visualize it is a nightmare.
-
@verius (For instance I can't just pull a list thats "here's all the router endpoints related to the API" - you have to hunt down every single router addition line that contains the addition of an API endpoint.)
-
@verius You're more familiar with the codebase than I am so rather than make suggestions that seem silly, I'll ask: How easy or difficult would it be to make the codebase load in feature modules dynamically? Because if this is relatively easy, what we could add as part of the API discovery methods, is a feature-detection methodology that can determine what software …
-
@verius If we can easily load in just the libraries for the functions we need, this would greatly reduce resource footprints in all but install size (and mustard is a small install as is).
-
@verius That's more or less what I was getting at doing. Have a core set of stuff we NEED to work for basic functionality, then have anything else be extra and based upon what we end up needing for extended features.
-
@verius The easiest way to my mind is something like TELOPT negotiation. But I'd be open to other ideas.
-
@verius My idea in this regard is this: 1] Custard makes a TCP connection with the pA API authentication endpoint 2] This endpoint verifies if the authentication is correct, if it isn't, it breaks at this point and sends an auth error 3] If the authentication information checks out, the pA API endpoint sends a communication of what features the server is configured …
-
@verius The benefit of this is you don't need a whole lot of logic to be in the client for different options. The server can enforce the client options as part of the session and output to the API in accordance with the negotiated options. There really isn't a downside to this as long as you have a mechanism to renegotiate options if the user changes them in a client.
-
@verius We could use a specific endpoint for renegotiation.
-
@verius Well, presumably, when you exit the settings screen.
-
@verius Well, basically what I'm describing is a handshake mechanism. What we'd need is a signal for both sides which they can interpret as needing to redo the handshake. It doesn't even have to be a complicated one.
-
@verius Easiest way is to just have a x-postactiv-sessionref header which would referenced the negotiated options. Any time that server-side settings change, drop the contents of the sessionref table and so each connection would have a new sessionref. Client goes "hey this is a new session, better renegotiate" and does so.
-
@verius As long as we make sure we avoid generating references which would be identical to previous ones, this should be fine.
-
@verius I think so too! :)
maiyannah
All Hacker Poesy content and data are available under the