actually worked mostly on documentation today, and JsonRpcClient becomes JsonRpcSocketClient, which makes it much less confusing to see on the server side
also fine-tuning the concept of a Controller (we need/want MVC semantics here)
ok #ImAnIdiot, it would be SocketController, and that would make things worse, because it's really a SocketClient. The "controllers" are the proxy classes with the [JsonRpcMethod] members (these handle "requests" from the server's client).
FWIW, I am not sure we want the MVC semantics. The communication should be purely data and the MVC concepts stay in the add-in piece and console windows exclusively. The only thing from MVC that'll go over the wire is the "M"odel.
really, it's more closer to "MC", rather than "MVC". but yes the controllers should be on the server side. IDK if the proxy is the culprit of confusion - it was easier conceptually for me to deal with interfaces that both client and server piece implement
Not even lol .. I think the interfaces need to go under Shared/RPC/Proxies, and the server side implements it and the client side invokes it, and which is which depends what the request/notification is
Yeah I don't like "proxy", but I think it's less confusing than "controller" would be
I'm trying to clean my excel sheet so that all lines match with each other when I put 3 different tables from 3 different data sets next to each other. The code I have gets the job done but it's really slow. I'm wondering if there is a much faster way for excel to delete.
Sub cleanSheet()
x = 3...
Yeah MVC-ish might make a bit more sense in the add-in LSP client, where we handle server notifications like "ShowMessage" and "OpenDocument", but also "CompletionList" and "PublishDiagnostics"
Still probably not... they're really proxies, not controllers :-)
@FreeMan because of abstraction levels: "socket" feels too close to the metal to see in a client app, I think. But yeah something like JsonRpcServerProxy is pretty much it.
Seriously, I don't think you're supposed to have either ServerProxy or ClientProxy... just Proxy -- (assuming I understood correctly that the proxy represents the common interface that both server and client pieces need to use for communicating)
> C:\projects\rubberduck\Rubberduck.Resources\Menus\RubberduckMenus.de.resx(273,2): error MSB3103: Invalid Resx file. Name cannot begin with the '<' character, hexadecimal value 0x3C. Line 273, position 2.
That's how.
(you'd think they'd make the error stand out at hte end, not buried under tons of blathering warning but....)
@this here's the catch: JsonRpc server receives a request from a client, never the other way around; so the "client" process is a JsonRpcClient when it sends a request to the "server", but then the "server" process is also a JsonRpcClient when it sends a request to the "client".
Since a proxy can be defined as an object that a client can use to make RPC calls to a server, it's always a "server proxy", so "ServerProxy" is a tautology... JsonRpcProxy is thus descriptive enough, but then JsonRpcServerProxy helps better describe its purpose and usage, absent xmldoc comments (which will definitely be there)
So JsonRpcProxy it is, with good xmldoc explaining where and when to use it
It's probably conceptually easier to grok if it's a FooResponse FooRequest(FooParam) and rather than void FooRequest(FooParam) and FooResponse GetFooResponse()
e.g. TelemetryProxy.Transmit() would always be called from a client to the server. If it's void, it's a notification. If it returns a result, it's a request =)
I think I'll make a "LocalDbServerProxy" that exposes all the LSP-to-LocalDb requests. Then there'll be a "LspServerProxy" for addin-to-LSP requests/notifications, and a "LspClientProxy" with all the LSP-to-client requests and notifications
so there's still a "request-response" cycle that we are accustomed with a traditional server-client model, but both sides are both the server and the client to each other, which is why the terminology becomes an obstacle. At least that's what I think.
brain goes "wait am I overthinking this?" and I shut it off immediately with "heck no, this needs to be well thought-out or we'll all curl into fetal position by Easter"
Turns out, LocalDb will have to be able to notify its clients, say, of configuration changes (say, trace verbosity)... or if I want it to support something like LSP's WorkDoneProgress notifications (we probably don't want that in LocalDb though)
So there's an ILocalDbServerProxy (server-side implementation) and an ILocalDbClientProxy (client-side implementation for sending notifications to the server)
And then an ILspServerClientProxy ....and yes, that means an awkward ILspServerServerProxy
Yes but there can be multiple LSP servers, plus the DB client app - any one of them could set DB server trace off at any time; server then needs to tell all its clients about the change
Ok I'm getting rid of the proxy wrappers (ILocalDbServerProxies), they're useless, confusing, and break SRP: if a class wants to use a proxy, it needs to know which one and take it as a ctor parameter
I'm trying to clean my excel sheet so that all lines match with each other when I put 3 different tables from 3 different data sets next to each other. The code I have gets the job done but it's really slow. I'm wondering if there is a much faster way for excel to delete.
Sub cleanSheet()
x = 3...
VBA Rubberducking
VBA Rubberducking