[Top][All Lists]

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

Re: [DotGNU]Butler = DGEE

From: Peter Minten
Subject: Re: [DotGNU]Butler = DGEE
Date: Tue, 14 Jan 2003 19:35:50 +0100

Chris Smith wrote:

> Okay.
> You're effectively capitalising on the middleware here.
> An extension to your idea would be someone running a DGEE on their unix box.
> They also want to run clients on the same box and point them at the DGEE.
> Now there is no reason why the DGEE and the 'CDGEE' below aren't essentially
> the same thing.  Ie it's a DGEE with the client side components there too.

You're right.

> I thinks it's a smart idea.  We truly do get an "Execution Environment" -
> whether it's client or server should be irrelivant?

Glad we're on the same track here :-).

> > There is just one small problem, the main GUI lib used at the moment is
> > FOX, but the FOX message passing system is a little different from the
> > DotGNU one. This is solved by wrapping the FOX message in a DotGNU message.
> > The message send to a FOX object would look like this on the 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 :-).

> I'd like us to offer a DGEE with a selection of transports and protocols.
> Webservices would be authored to use one of the protocols (xmlrpc, soap....,
> jabber-xml) but perhaps over a range of transports that support the
> facilities used of the protocols (http, smtp, Jabber).
> A single webservice cannot accept multiple protocols (xml-rpc, soap etc) (the
> solution to this is to vaneer off the functional part and provide different
> protocol interfaces on top of that).

That's what I'm trying to achieve with message passing.
> So donkey work such as the packaging you describe above is only necessary if
> you're forced to use a particular protocol.

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.

> And you're forced to use XML-RPC 'cos it's all we have at the moment, and
> incomplete :o(
> > I imagine the Client DGEE (CDGEE) working like this:
> >
> > The user gives commands to the CDGEE through a locally running webservice
> > app (yes I know it's not a webservice if it's not accessible from a
> > network, but you get the point :-) named Webshell. The CDGEE then creates a
> > webservice process which accesses the webservice on the server and goes
> > through the whole auth process. The local webservice process is linked with
> > the UI libs and can thus provide a User Interface for the remote
> > webservice.
> 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.

> You've got a few options here.
> - You can ask the CDGEE to do the authentication out your behalf, and then
> carry on doing direct ws requests to the remote dgee yourself (which won't
> work if the CDGEE-Butler is supposed to help with the data marshalling).
> - Your client app could connect to the CDGEE and get it to do the
> authentication and other calls on your behalf.  Kind of active proxying.

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



reply via email to

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