search

patrickfrey / strusWebService

web service (HTTP/JSON) to use the strus API as a service
http://project-strus.net
Mozilla Public License 2.0
4 stars 0 forks source link

architecture redesign in core #38

Closed andreasbaumann closed 6 years ago

andreasbaumann commented 6 years ago

Currently we use too many mutexes for things which are already synchronized in strus itself, we don't share certain sharable objects (as the QueryProcessor) and thus have to recreate the module functions on every query call. As the storage interface is bound to change anyway, a major overhaul of the core architecture is needed.

andreasbaumann commented 6 years ago

We should try to use the strusModule proxy layer, otherwise we cannot use strusTrace.

andreasbaumann commented 6 years ago

Furthermore restarting modules is not a problem as long they do not have big resources, which are prohibitive to be loaded per query.

andreasbaumann commented 6 years ago

One request with ins,del,del,ins is rest.

A sequence of requests:

begin
ins
ins
commit

is not REST.

andreasbaumann commented 6 years ago

Error handling is thusly complicated because we have to roll back transaction in all kind of situations (e.g. broken pipe). Cppcms doens't help us there (because it's not it's job). Also this makes me inclined to drop transactions.

andreasbaumann commented 6 years ago

On the other hand there are ideas like WS-Transactions. Especially because also web services are not always the root of the transaction but could be part of a much bigger transaction going on.

andreasbaumann commented 6 years ago

Another point of view is, that all protocols like RPC, SOAP, Corba were supposed to start out simple and finally ended up implementing authentication, transactions, etc. Why not REST?

andreasbaumann commented 6 years ago

Another issue is error handling (the catch(...) in writing to the lost client).

andreasbaumann commented 6 years ago

Currently sticking to the idea of REST and transactions. transaction/begin merrily creates a resource no the server called transaction (whether the server or the client names it, is not important). Insertions and delete operations now reference the transaction (as they reference the index). This is perfectly sane from a REST perspective (at least IMHO).

patrickfrey commented 6 years ago

The new WebService implementation follows REST to a great extent. I close this issue though there some good ideas collected here.