TODO: REST, HTTP, Client/ServerPersistenceEngine about neventstore HOT 3 CLOSED

Should this really be another REST/HTTP abstraction? Depending on what PersistenceEngine you use you are already doing a RPC. In case of Raven even a HTTP request.

Is abstracting the transport away from the already existing protocols really necessary?
Users can come up with weird configurations like "Raven -> HTTP -> PersistenceEngine -> HTTP -> EventStore"

What is the use-case for this?

from neventstore.

I was thinking for systems like a File-based implementation, e.g.

User -> Domain -> Repository -> EventStore -> (HttpPersistenceClient) -> (HttpPersistenceServer) -> File-based Storage.

from neventstore.

What we have is, for sql, mongo etc:

• App -> Repository -> EventStore -> TCP\NamedPipes\etc -> Persistence

Access\SQL are of course, embedded.

What I would like to see is, which is very similar to RavenDB:

• App -> Repository -> EventStore Client -> HTTP -> EventStore Server -> Persistence (File or embedded db such as Esent)

or optionally:

• App -> Repository -> EventStore Client -> HTTP -> EventStore Server -> TCP -> Persistence (Sql etc).

I'd expect the EventStore client to have same API as non-http version. And then expand to include similar to raven's multi-tenancy, applying security to streams and that sort of thing.

Just some thoughts... am half tempted to re-open this...

from neventstore.