[Top][All Lists]
[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