Events, authentication, C#

[DavidTurner]

Hello

First off, I've been looking for a project like Ice for a while. I think it's great .

I have a mixed bag of comments, questions and suggestions:

1. Why not implement event semantics a la .NET? I realise that this approach has scalability issues, however there's nothing to stop you using the full-blown event service when you need scalability. And an event with only a few listeners is a common case.

2. Let's say I want to implement a service registry similar to IceBox, which will also provide authentication services. I authenticate myself to the server, and the server then directs me to a third party (that is, it gives me a proxy object). That third party wants to check if I'm legitimate; so somehow it has to know who I am. Once it knows who I am, it can check with the server to see if a certain level of access is available. Would it be possible to provide that "who-is" information in the form of a cookie supplied to the proxy by the server, rather than implementing an IIsAuthenticated interface on all the clients?

This business of cookies generalizes to: "can I pass extra information to the third party via the proxy I give to to the client?"

(Update: I see you specifically don't do this, so as to keep your proxies simple)

3. What are the plans for the C# mapping? I'd like to help out.

Regards
David Turner

[marc]

Originally posted by DavidTurner
Hello

First off, I've been looking for a project like Ice for a while. I think it's great .

I have a mixed bag of comments, questions and suggestions:

Thanks, we are glad you like it!

Originally posted by DavidTurner
1. Why not implement event semantics a la .NET? I realise that this approach has scalability issues, however there's nothing to stop you using the full-blown event service when you need scalability. And an event with only a few listeners is a common case.

I'm afraid you have to educate us a little bit about .NET. What kind of special event semantics does .NET have?

Originally posted by DavidTurner
2. Let's say I want to implement a service registry similar to IceBox, which will also provide authentication services. I authenticate myself to the server, and the server then directs me to a third party (that is, it gives me a proxy object). That third party wants to check if I'm legitimate; so somehow it has to know who I am. Once it knows who I am, it can check with the server to see if a certain level of access is available. Would it be possible to provide that "who-is" information in the form of a cookie supplied to the proxy by the server, rather than implementing an IIsAuthenticated interface on all the clients?

This business of cookies generalizes to: "can I pass extra information to the third party via the proxy I give to to the client?"

(Update: I see you specifically don't do this, so as to keep your proxies simple)

You can pass extra information in the context parameter. The context parameter is specifically intended to pass along information *about* a request, such as routing information (like in Glacier), or information about a transaction a request belongs to.

What's currently missing is the ability to set a default context. At present, the default is always empty, meaning that you always have to pass the context explicitly. But this will change in a future version.

Originally posted by DavidTurner
3. What are the plans for the C# mapping? I'd like to help out.

We currently don't have (commercial) demand for a C# mapping. Should such demand come up, I think it would be pretty straightforward to implement. Personally, I like C#. It has some nice improvements over Java.

[DavidTurner]

Originally posted by marc
I'm afraid you have to educate us a little bit about .NET. What kind of special event semantics does .NET have?

In C#, events look like this:[list=1][*]Declare a "delegate" type, meaning a callback type:
delegate void EventHandler(args);[*]Declare an "event" of that type:
event EventHandler MyEvent;[*]Subscribe to the event:
MyObject.MyEvent += new EventHandler(MyHandler);[*]Generate the event:
MyEvent(args);[/list=1]
I think the syntax could be improved: the idea of a delegate is actually an implementation detail, not an entity in its own right. But the basic idea is that interfaces/classes support events as first-class members, and the language (or in this case, Ice) takes care of maintaining the subscriber list. It also means that you don't have to have a separate callback interface for each type of event, and resolves all those hassles with colliding callback names - with this model, I can subscribe to two similar events using different functions, rather than passing context.

You can pass extra information in the context parameter. The context parameter is specifically intended to pass along information *about* a request, such as routing information (like in Glacier), or information about a transaction a request belongs to.

You mean the one mentioned in 6.11.1? Hmm.

What I'm really after is some sort of automatic connection tracking, such that the server can tell "who's asking" by means of each client having a unique id attached to the proxies it gets (cookies! ). The client shouldn't be aware of it at all. I could possibly hack the same information out of the SSL certificates, but not reliably. Am I missing something obvious?

Note that the "server" I'm talking about may be distributed over several machines...

Some more about the events, as a postscript:

I find that I use events far more than properties these days. In fact, my ideal object consists only of events and methods. Think about it. Properties are properly encapsulated as method calls, and asynchronous transactions are just about as common as synchronous transactions.

The way I would do events is as follows:

class MyServer
{
event MyEvent(args);
void some_function() { MyEvent(args); }
}

// subscriber:
MyServer& svr = ...;
svr.MyEvent.subscribe(MyCallback);
svr.MyEvent.unsubscribe(MyCallback);

[mthiercy]

Just some additional comments about 'events'.

The 'delegate' and 'event' models in C# are syntactic sugar to implement asynchronous callbacks. The issue with C# is that the syntax is not fully consistant (in my opinion) and the type checking is weak.

But, I agree with the potential of making objects work together by sending asynchronous messages (i.e. events) as it greatly simplifies programmation. A very nice library that uses it is Qt (with notions like SIGNALs and SLOTs), but it requires pre-processing (moc). An excellent C++ add-on that does the same thing is freely available with "sigslot" (http://sigslot.sourceforge.net/). Written entirely with the C++ template mechanism (generic programming), it helps connecting objects without any knowledge from each other (weak coupling).

[DavidTurner]

Originally posted by mthiercy
Just some additional comments about 'events'.

The 'delegate' and 'event' models in C# are syntactic sugar to implement asynchronous callbacks. The issue with C# is that the syntax is not fully consistant (in my opinion) and the type checking is weak.

Yes, they are syntactic sugar, but they're not "just" syntactic sugar, since they actually extend the scope/power of the language. Sigslot is clever, but it is a terrible hack (like a state machine trying to be PDA ).

I agree with you about the syntactical consistency and type checking.

It is actually possible to implement sigslot-type events with something like Ice (or CORBA) inbetween. It isn't pretty, though, and the syntax certainly doesn't make ones intentions clear.

Events deserve to be first class interface members more than properties do.