Purpose of inprocess servers

[Gabriel Aszalos]

Hello again Upspiners,

Going still deeper into understanding the inner workings of Upspin, I've ran across more questions. I hope you don't mind me probing and questioning design decisions, as my intention is purely to learn and potentially help out (considering you'd allow me to) with improvements or ideas.

Question

What is the purpose of the "inprocess" versions of each server?

Assumption

Searching through the codebase, I can see that the inprocess versions are mostly used in tests. Am I correct to make the assumption that these packages were created in order to be able to piece together the Upspin environment in a simpler, less externally dependent manner (without external storages, etc) in order for it to be more easily tested?

Problem

If the above assumption is correct, then the ideal scenario would be that these tests should also guarantee the correct working of {key,store,dir}/server, which may not always be correct with the current setup because a lot of logic is duplicated between {key,store,dir}/server and {key,store,dir}/inprocess, but there still remain small differences. Changes on one side may not propagate to other creating inconsistencies. I think the only conceptual difference between the two is the place where data is stored.

Suggestion

Assuming that I've been correct so far with the above points, would it not be a better approach to get rid of the inprocess servers and instead create in-memory storage.Storage that can be used with {key,store,dir}/server in the same manner, making tests as easy as before but more accurate and reliable. The configuration is already there and plugging a simple in-memory storage should be a piece of cake. This would ensure that the server code that runs in tests is the same as the ones running in "production".

I do have a hunch that I might have not gotten a good grasp of these concepts and that perhaps these "inprocess" servers serve a different purpose, but hopefully you'll help me clarify.

Thank you for reading and for your patience!

Gabriel

[Rob Pike]

You are correct, the inprocess servers were created for testing, but also because they were simple ways of probing the API while it was being designed.

They do not verify the exact behavior of the network servers, of course, but they do serve as a second complete implementation that can be used to verify corner cases and such, providing an indirect test of the other implementations. Like having two compilers for a language, it's always a good idea to have two implementations of a complex design.

We have no plans to delete them.

-rob

--
You received this message because you are subscribed to the Google Groups "Upspin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to upspin+unsubscribe@googlegroups.com.
To post to this group, send email to ups...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/upspin/65e40e2f-afe6-4307-8ffc-51a36c962693%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gabriel Aszalos]

Thank you for clarifying Rob, that is indeed a good idea to verify the implementation. Perhaps my choice of words might have been a bit bad by saying "to get rid of". I wasn't trying to say to delete them, I meant to use more of the actual servers in the tests, but after taking a closer look, I think you already do use both. Sorry for being confused, still learning my way around.

To unsubscribe from this group and stop receiving emails from it, send an email to upspin+un...@googlegroups.com.