dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]Butler = DGEE


From: Chris Smith
Subject: Re: [DotGNU]Butler = DGEE
Date: Thu, 16 Jan 2003 12:46:46 +0000

On Tuesday 14 January 2003 18:35, Peter Minten wrote:

> > > DotGNU level:
> > > ____OBJECT______MEMBER____ACTION__________CUSTOM_DATA______
> > > ("objectname", "handle", "invoke", [selector, message_data])
> >
> > Yes, you'd have to do this for XML-RPC, but if you use another protocol
> > then this would perhaps be unnecessary.
>
> IMHO the system should be the same whether used in XML-RPC, SOAP, CORBA or
> something else, that saves us a lot of bugs and is also elegant :-).

Yes.  I'm suggesting that our API automatically takes the data you're sending 
and 'folds' it into the form suitable for the chosen protocol, XMLRPC, SOAP 
etc. The client/webservice author just uses the standard consistent top level 
api and the architecture takes care of everything else.

> Wait a sec, this is not about circumventing XML-RPC weaknesses if that's
> what you think. I mainly like message passing because it's flexible and
> simple. For example you could hook something onto an event by simply
> providing object, member and message type strings and it would work.

No, I was getting at the folding thing :o)


> > Is butler was supposed to do intelligent marshalling of data as well as
> > authentication?  Correct me if I'm wrong.
>
> Well it's what you define as intelligent :-). The Butler would basically
> have acted as a mail sorting machine, it would have make incoming data
> arrive at the right client process based on who send it. Authentication
> would also have been a task of the Butler since it would have been the only
> DotGNU component on the client side.

Okay.
If you're client sends things through the [c]dgee which calls the remote dgee 
on the clients behalf, then [c]dgee will get the incoming data back to the 
appropriate client as the dgee is built on a messaging middleware :o)
hehe

How we build this client->cdgee->dgee->cdgee->client into the architecure 
will take some designing though.

> Wouldn't it be better if the DGEE wouldn't bother itself at all with auth
> but leave it up to Webshell (which basically takes on half of the Butler
> job, DGEE the other half)? Webshell could also handle stuff like loging in
> on the auth server.

But what is webshell?  I mean, it's a process of some sort... so wouldn't 
that be a natural component of the cdgee?  Which is what I was hinting at I 
think - that the 'auth' stuff could be deployed as a dgee component so comms 
with it can be done the same way as other dgee stuff.
Just an idea - I need to know more about where (litterally)  webshell fits in 
etc.

Hey, we're fleshing this out a bit aren't we ? :o)

Cheers,
Chris


-- 
Chris Smith
  Technical Architect - netFluid Technology Ltd.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk


reply via email to

[Prev in Thread] Current Thread [Next in Thread]