Tabling is certainly cool and I’m looking forward to when we can have nodes which provide users with built-ins for tabling in addition to the built-ins available in the ISOTOPE or ACTOR profile. But I think we should start simple, and design something that can be easily implemented and easily standardised, so I think tabling on that level must wait.
You seem to suggest that tabling can be used for internal purposes as well, as a technique for doing what we do with our caching scheme. Isn’t what you describe yet another way to cache solutions, rather than caching pengine processes that, as it were, have “more to give”? For caching of solutions, I think what’s already available on the Web in the form of intermediates that do caching of responses to stateless requests will take us a long way towards scalability.
I must say I’m very happy with the current caching scheme. It shows, I believe, that there exists at least one method that allows us to offer a stateless HTTP API which avoids a lot of recomputation. It may be that your proposal would also work, and may be better than ours, and there may be methods that are far superiour to both of our proposals. People should be allowed to build an ISOBASE node using the old CGI technology if the want to. It won’t be fast, but it’s possible to make it conform to a future Web Prolog ISOBASE standard, precisely since such a standard won’t prescribe a particular way to achieve statelessness.