Notification support in 1.2

[Oren Eini (Ayende Rahien)]

One of the things that we intend to do in 1.2 is support the notion of notifications.

The issue for this is:

http://issues.hibernatingrhinos.com/issue/RavenDB-268

The basic API is planned to be something like:

IObservable<DocumentNotification> x = store.DatabaseCommands.Notification();

The idea is that you can subscribe to things like put/delete as well as replication put/delete and conflicts.

 I thought about doing this with SingalR, but that puts us back with the issue of json.net dll and the issues that it brings.

Any ideas?

[theouteredge]

WCF? ;)

On May 26, 3:05 pm, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:

[Oren Eini (Ayende Rahien)]

Um... no.

[codin...@googlemail.com]

Hah yeah, please god no! :)

Sent from my iPhone

[Damian Hickey]

Does this need to be compatible with SingalR clients (.net\ js) or is it an internal concern between ravendb's client and server?

[Oren Eini (Ayende Rahien)]

I don't care for compatibility, no

[Samuel Jack]

As I see it, there is not the same problem using SignalR here, as there is with Json.Net. The difference is that RavenDB exposes Json.Net types, whereas our use of SignalR would (I think) be a completely internal implementation issue, so we could ilmerge the SignalR libraries without any difficulties.

That said, we would be exposing IObservable<T>. On the desktop that wouldn't be a problem, because IObservable itself is baked into the BCL as if .Net 4.0. But in Silverlight, this would require us taking a dependency on the Rx framework. Then we would be back in the Json.Net scenario, and this time without the option of embedding the source code.

On Saturday, 26 May 2012 15:05:39 UTC+1, Oren Eini wrote:

[Samuel Jack]

Thinking about this further, to avoid the Rx-dependency problem, we could expose notifications as events only for the Silverlight client. It is an easy matter for users of the API to convert an event into an IObservable using which ever version of the Rx they like - we can have a Gist for this.

We could still use Rx internally, but we could then ILMerge it without a problem.

[Oren Eini (Ayende Rahien)]

Samuel,

That is possible, sure, but there are a few issues here:

- It complicate our lives, in the sense that we need more complex build process - but we already have a fairly complex one already

- We already would need a custom build, because SignalR depends on json.net

[Itamar Syn-Hershko]

Given this is going to be a bundle, and  I don't think there's any other good alternative to SignalR, this will have to depend on them and on the way they are planning to resolve this conflict. I presume they are aware of this and are working towards a solution.

[Oren Eini (Ayende Rahien)]

It isn't going to be a bundle, it is going to be part of the core.

[Itamar Syn-Hershko]

So I'd suggest keeping this as a bundle until that issue is resolved on their side

[Oren Eini (Ayende Rahien)]

I don't see how that can be done, and I don't want this to be a bundle.

[Samuel Jack]

The SignalR team have already taken some steps towards isolating the dependency on Json.Net (see, for example IJsonSerializer). This isn't done consistenly, however. For example, IParameterResolver has an method which takes JToken as a parameter.

Maybe a solution would be to work with the SignalR team to complete the work of isolating it from a hard Json.Net dependency, and then we can supply implementations of the interfaces which work with the embedded Json.Net?

I'm sure other teams would thank us for it!

Oh ... I see Oren is already thinking that way  https://github.com/SignalR/SignalR/issues/424 :-)

--

Samuel Jack

Seaturtle Software Ltd

Tel: +44 (0)7811 557230

Skype: samuel_d_jack