Hi Ben,

> From: Ben Tilly [mailto:ben_tilly / hotmail.com]
> Sent: Sunday, December 10, 2000 1:02 AM

> > > dRuby really has not much to do with SOAP.  dRuby is a
> >
> >Agreed.
> >
> >I who implemented SOAP4R and Seki-san who implemented DRb
> >talked about co-working of SOAP and dRuby.  We thought below
> >possibilities.
> >
> >- dRuby over SOAP
> >- SOAP over dRuby
> >- dRuby/SOAP bridge
> ^^^^^^^^^^^^^^^^^^^^^
> 
> >- SOAP as a RPC part of dRuby
> 
> The bridge is the only one that could make sense to me.

Hmm.  I have to consider it again.  Do you think a bridge
like this?
  Ruby - dRuby/SOAP - Perl, Java, C++, and so on
In this case, do we support MBR(Marshaling By Reference)
which dRuby supports but SOAP does not supports originally
(we can extend using SOAP Header).  Reference of Ruby object
passed from dRuby to other program which is written in other
language like Perl, Java, C++, and so on won't work well...
at least it won't be "quick and easy object-oriented
programming".

MBV(Marshaling By Value) should be supported by the bridge
and could be useful I think.  When you write a Ruby
application and want to export the method which is stateless
as a service to the Internet, dRuby and dRuby/SOAP bridge
would help you.

> >These do not make sense to us now...  SOAP is independent
> >from programing language.  dRuby is Ruby specific (so dRuby
> >applications are Write Once, Run Anywhere where Ruby runs).
> >They could kill characteristics each other.  Folks, how do
> >you think?
> 
> I think that Bruce Schneier is absolutely correct that by
> building an internet prototol with no security model which
> is hard to filter, SOAP will be responsible for a new host
> of security holes.
> 
>   http://www.counterpane.com/crypto-gram-0006.html#SOAP

Agreed.  DCOM over HTTP is required but not adopted much.
SOAP and XML-RPC is to be the next candidate but we do
care security vulnerabilities as he said.  Transport
seurity SSL might help for some purpose.  Messaging
security XML-Signature might help for another purpose.

> I have not looked at druby.  However if you could internally
> implement some of the ideas of a capability system, that
> would be very, very good.  I first ran across these at
> http://www.eros-os.org/, he has a nice introduction to the
> ideas at http://www.eros-os.org/faq/basics.html.
> 
> Basically it works like this.  Access is provided through
> objects.  You can only name resources through objects.  If
> you can name a resource then you must have had permission
> to access that.  If you cannot name it, then you have no
> business knowing that it exists.
> 
> Contrast to the usual authentication based on (purported)
> id.  On a Unix system if any program anywhere that runs as
> root gets compromised, then the whole system is at the mercy
> of the person who just broke in.  On a capability system
> that program does not run "as" anyone, it just had the
> necessary capabilities to do what it needed to do.  So the
> compromise is limited in scope.

Thank you for explanation.  dRuby now uses ACL which
Capability system negates (IIRC; Seki-san?).  Capability
system or its idea seems to be helpful for building
Application server using dRuby.  Can dRuby itself support
this idea?

> >// NaHi
> >// Sorry for my poor English.
> 
> Sorry for not speaking Japanese!  (There is no need when
> doing us a favour in speaking our language to be apologetic
> for not being perfect!)

Doumo arigatou gozaimasu.  Many thanks.

// NaHi