Re: [DotGNU]Message passing between webservices

[Gopal V]

If memory serves me right, Chris Smith wrote:
> I'm thinking that we basically want to derive from MS's attributes as much as 
> we can, and then add our own functionality etc on top.  Thus .net services 
> have a chance of running under DotGNU, but not the other way round, which was 
> our baseline anyway.

Which is what me & Chris have talked for hours on IRC ... we had finally
decided to support stuff which will looks like MS Stuff for developers but
with something radically different inside ... (maybe not, but we really 
don't know what MS is doing inside :)

> However, as the protocol stuff is (or will be....) handled by the inherited 
> interface classes. we can provide whatever transport protocol we like as the 
> above (attributes) will sit on top.

Hmm... 

> wouldn't do object serialisation over xmlrpc (i don't think).

You *can* do Object serialisation over xmlrpc ... but the obvious question
is "do you want to ?" ... Of course not ! ... it would be a cinch to serialize
Objects into <structs> provided they do not have circular inclusions ....
(because XmlRpc does not have a reference tag and will always use values for
 objects).

> In terms of property access, You'd never access a property directly anyway 
> but provide a method to do this.  C# does this kinda automatically with the 
> set_ get_ syntax but you (the ws author) still need to provide the body of 
> these functions.

So what do you want ? ... this ?


public static int FooBar
{
        [WebMethod("GetFooBar",....)]
        get
        {
                ...
        }
        set
        {
                ....
        }
}

and get these methods out of it ? "int get_FooBar();" and "void 
set_FooBar(int);" ? ... I think this generates .dgmx with get_Foobar
and no set_Foobar ... but the Invoke might need some help with that.

> Externally property access looks just like member access (and so it should!) 
> so Xml-Rpc and thus all protocols will be fine.

Hmm.. how about my idea ? "get_" and "set_" methods explicitly ? 

> Yes it will <grin>.
> If you want state, then the webservice is built to provide state (ie the 
> state property of the WebService attribute is set).  This has the effect of 
> making the object/class serialise itself on destruction (or at the first 
> point at which execution leaves the class).  The object is serialised to some 
> central storage shared by the execution environment.  This is all done for 
> you.

We have an edge if some of our base classes can offer this facility ? ...
(because just running IL off a webserver like ASP.Net does not provide that).
Since we have our own middleware system, we can offer that IMHO .... (remember
internal calls) ... 

session=DGEESessionManager.RegisterSession("gopal","t3rmin4t0r","*****");
session.AddKey("name","Gopal.V")... etc...

and finally send 

session.ToID(); // or ToHash();

....

> The original caller (who did the set) gets a session reference back.  When 
> they do the get_ call, the session reference is sent too enabling the 
> execution environment to restore its state and satisfy the request.

session=DGEESessionManager.RecollectSession(sessID);

Since we have Goldwater to synchronize between the Apache children, we can
do this efficently and faster than using a call to a database server !!! ..

And From the looks of it *anything* is faster than ADO.Net :). This however 
requires us to work on the Serialization API which has been unimplemented IIRC.

> Ah, it "has state" in that it has somewhere to store the state key. Using 
> Jabber makes us no better off because we still have to arrange for state to 
> be restored on the back end.  Jabber is a protocol that supports state 
> natively in it's protocol - so is probably *the* best protocol to use with 
> DotGNU state-friendly web services.  There will be others too.

Yeah... Jabber is conversational unlike the "We exist to Serve" attitude of
HTTP ! .. Jabber means that the server can *push* stuff as well as client
pull ... And of course you can recieve queued messages via jabber as well.
(which is like giving a google search, disconnect, come back after 2 hours
 and get the results)

IMHO Jabber combines the directness of HTTP with the queuing of SMTP .. 
(which is good , though I don't like the idea of webservice spam).

A lot of revolutionary stuff is possible with this framework, but we don't
want to be premature on the market ... But first the foundation design 
has to be complete and rock steady on the development side ... Till then
let's propose,refine, ad infinitum...

Gopal
-- 
The difference between insanity and genius is measured by success