[ruby-talk:20262] Re: CORBA Ruby mapping

> Sorry, I haven't checked the newsgroups for awhile.  I'm extremely
> busy right now and will not be able to work on any CORBA stuff for at
> least a few weeks.  Did you get the tarball to compile and work?

  Hi Tobin, you need not mind it.
  I suspect I'll be busy incoming a few month because of as employment and because I'll
join new small opensource project.
  (ah why are there many and many issues which urge me hack? ;-) )


  I've gotten your code(thanks for your help about downloading) and roughly read source code,
but have not compile or run it.


> I agree that common classes like system exceptions, a union type, an
> any type, a fixed-point type and (maybe) enums are needed.

  Sounds good.
  Although these mey not be so big code, shall we open CVS directory for commiting
our fragment code which will be created in our intermittent free time?
  (At sourceforge, I like.)


>  But I
> guess I don't see the need for common stub/skeleton interfaces like
> Java.  The Java portable stub/skeleton interface is important because
> it guarantees the portability of client code.

>  But I'm not convinced
> that Ruby clients should be using stubs/skeletons in the first place. 

  I also agree that stub/skeletons need not be seen from developer.

  I don't claim that all developer of client or server should generate stub/skeleton
from IDL before running his application.
  We should supply API which dynamically compile IDL and generate stub/skeleton then load
it, such as your new ``require'' method.
  (But I don't understand the need to replace standard require method)

  I claim to standardize an interface between ORB and client/server code.
  For example, how to stub marshall and send request to ORB.

    //IDL
    short foo(in short arg);

    # stub
    def foo(arg)
      buf = _request()        # how to get ORB's message buffer to send?
      buf.write_short(arg)    # is it better for buffer using the write_ method?
      ret = buf.invoke("foo") # when and how stub pass method name to ORB?
      return [ret]
    end

  other stub code is possible.

    # stub
    def foo(arg)
      buf = _request("foo")
      buf.puts({"short" => arg})
      ret = buf.invoke()
      return [ret]
    end
  
  It is no benefit that there are many different interface but do substantially same work.


  Separating stub/skeleton generator and ORB make it possible:
    - for client/server developer to choice stub/skeleton generator and ORB independently.
    - for ORB implementor to separate these code and keep it simple.
    - for ORB other than CORBA easy to connect our platform.
    - after all, these scheme may be need for DII or DSI.


  And its defect I think are:
    - All ORB implementors need a bit more work. But it is not so hard.
      He or she need to create only simple wrapper for his/her ORB implementation.
      (My ORBit wrapper use its style.)
    - Any developer who interested in how ORB work can see stub/skeleton code.
      I think it is rather a good environment than environment of which developer cannot
     get internal information.


-- 
  DAi.K. <[e-mail]>