siop-development — SIOP Development

[Siop-development] Siop Version 0.2.0 released

[Rapheal K. <ra...@ma...>]

  I put a release file up on Sourceforge just in case anyone wanted to do a 
simple download without needing to hook in to the CVS server.  Hopefully, 
this might encourage new people to take a look and TRY to figure out what 
SIOP/SNAPP is doing.

  It's only a source tar-ball.

Re: [Siop-development] Passing by value and by reference

[Rapheal K. <ra...@ma...>]

>>   Now it's a little easier:
>>
>>
>>     # Helper method to define Python class
>>     # In the future, may provide helper library to do this
>>     def pyclass( name, *parents, &definition )
>>         klass = $types.ClassType(   name.to_s,
>>                                 Siop::val( Siop::Tuple( *parents ) ),
>>                                 Siop::val( {} )
>>                                 )
>>         klass.instance_eval &definition unless definition.nil?
>>         klass
>>     end
>>     
>
> I would hope that code like this would be part of the siop framework, at
> least at some point. You're not going to expect a siop user like me to
> write or maintain code like that, are you? 
>
>   
  Meaning, siop will include code for creating classes?  I think that 
class creation should be one of the levels.  Then it would be a lot 
simpler to code the above thingy.  There would, for one, be no need to 
do the val thing nor the tuple thing, because the bridge on the 
receiving side could take care of all of that for you.



> I had a similar reaction to the wxRython snippets...they seemed to be a
> mix of generic and specific code. I don't want to see the sausage-making
> generic code. It's all about encapsulating the icky parts into the
> framework so clients like us can just use remote classes and objects as
> if they were local.
>
> Something like this would be cool:
>
>   class MyApp < siop.remote_class(:wx, :App)
>     def on_init
>       # blah blah blah
>     end
>   end
>   

  Right, that's what I am thinking.

Re: [Siop-development] Passing by value and by reference

[Kevin S. <wx...@qu...>]

On Thu, 2006-06-29 at 00:43 -0700, Rapheal Kaplan wrote:
>   I've added a "ref" and "val"... err... modifier?  Not sure what to call 
> them.  

Seems ok.

>   Remember, scalar values are passed by value by default while collections are 
> passed by reference by default.  

Still sounds irritating to me, as one who is constantly fuming about the
scalar/object distinction in Java. Maybe this wouldn't be so bad, since
as I mentioned Ruby passes ints by reference but they appear to be
passed by value since they are immutable.

>   Now it's a little easier:
> 
> 
>     # Helper method to define Python class
>     # In the future, may provide helper library to do this
>     def pyclass( name, *parents, &definition )
>         klass = $types.ClassType(   name.to_s,
>                                 Siop::val( Siop::Tuple( *parents ) ),
>                                 Siop::val( {} )
>                                 )
>         klass.instance_eval &definition unless definition.nil?
>         klass
>     end

I would hope that code like this would be part of the siop framework, at
least at some point. You're not going to expect a siop user like me to
write or maintain code like that, are you? 

I had a similar reaction to the wxRython snippets...they seemed to be a
mix of generic and specific code. I don't want to see the sausage-making
generic code. It's all about encapsulating the icky parts into the
framework so clients like us can just use remote classes and objects as
if they were local.

Something like this would be cool:

  class MyApp < siop.remote_class(:wx, :App)
    def on_init
      # blah blah blah
    end
  end

Kevin

[Siop-development] Passing by value and by reference

[Rapheal K. <ra...@ma...>]

  I've added a "ref" and "val"... err... modifier?  Not sure what to call 
them.  They are intended to be simple markers that a host language can use as 
a hint to the bridge so that the bridge knows to over-ride the default 
parameter behavior for an object being passed to a peer either via parameters 
or return value.

  Remember, scalar values are passed by value by default while collections are 
passed by reference by default.  These little keyword thingies can over-ride 
this default behavior.  So, let's say you were calling a method that uses a 
list.  It might be the case that the programmer can figure out that it would 
be an optimization to send the list to the other side, especially if the code 
over there does a lot of random access:

  remote_object.helpful_method( val( [ "a", "b", "c", "d" ] ) )

  The example above would send a reference to the list if it were not for the 
modifier wrapper object.

  This is very useful in the example wxWidgets code where we needed to 
construct native Python tuples and dictionaries in order to be able to create 
new classes:

    # Helper method to define Python types
    # Class creation requires actual Python tuples, not pretenders
    # TODO: This can be disposed of when it is possible to pass
    # tuples by-value
    def tuple( *stuff  )
        list = $types.ListType.call
        for thing in stuff
            list.append( thing )
        end
        $types.TupleType( list )
    end

    # Helper method to define Python class
    # In the future, may provide helper library to do this
    def pyclass( name, *parents, &definition )
        klass = $types.ClassType(   name.to_s,
                                tuple( *parents ),
                                $types.DictType.call
                                )
        klass.instance_eval &definition unless definition.nil?
        klass
    end


  Now it's a little easier:


    # Helper method to define Python class
    # In the future, may provide helper library to do this
    def pyclass( name, *parents, &definition )
        klass = $types.ClassType(   name.to_s,
                                Siop::val( Siop::Tuple( *parents ) ),
                                Siop::val( {} )
                                )
        klass.instance_eval &definition unless definition.nil?
        klass
    end

  Anyone who thinks they follow this and cares to voice their opinion as to 
wether this seems ok or is cumbersome, or thinks there might be a more 
preferable way, please tell me.

  - Rafe

Re: [Siop-development] Any framiliar with JSON?

[Kevin S. <wx...@qu...>]

We're using json on the CMP project, as a data storage format. I really
like it.

The "standard" java bindings are under a crazy license that's not
compatible with any other license on the planet (and probably isn't
enforceable either). Fortunately, we found an earlier version that was
under a very liberal license, and it has worked fine for us.

Feel free to ask off-list for more details.

Kevin


On Sun, 2006-06-25 at 16:21 -0700, Rapheal Kaplan wrote:
>   I reckon JSON could actually provide a decent way to implement a useful text 
> protocol for the SIOP transport layer.  Does anyone know it?
> 
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Siop-development mailing list
> Sio...@li...
> https://lists.sourceforge.net/lists/listinfo/siop-development

[Siop-development] Any framiliar with JSON?

[Rapheal K. <ra...@ma...>]

  I reckon JSON could actually provide a decent way to implement a useful text 
protocol for the SIOP transport layer.  Does anyone know it?

[Siop-development] I'm even using Eclipse now

[Rapheal K. <ra...@ma...>]

  There you have it.  Now none of you have an excuse for not looking at Siop.  
Since I am doing Java bindings now, I have created and checked in an Eclipse 
project.  That means that those of you who need to use Eclipse to get dressed 
every morning can look at stuff.

  Like the Python bindings, I am finding there is a lack of unit tests that I 
am running on the Java code directly.  This is a bug, not a feature.  In the 
meantime, I am able to still use the Python tests to check the compatibility.  
Indeed, Java's bindings already pass a number of the pipe tests.

  I also went looking around at a few other projects on Sourceforge.  I think 
that this is the farthest something like this ever got, and some people had 
similar ideas.

  I feel good about it.  All the pieces seem to be making sense, at least to 
me, but then it always seems like that when I work alone.

  - Rafe

[Siop-development] Java bindings

[Rapheal K. <ra...@ma...>]

  I am getting a head start on the SIOP Java bindings.  Very exciting.  Hear 
that Nathan?  I am beating you to the punch, just as if it was important.

Re: [Siop-development] How to implement the "Tuple" type in Python

[Rapheal K. <ra...@ma...>]

  I found a use for Tuples in Ruby, but you will hate it, and frankly I think 
it's a little weird.  However,  these kinds of differences in how languages 
works needs to be allowed.

  The ruby [] operator can take between 1 and 2 parameters.  It's the only 
language that comes to mind that allows for this kind of syntax.  Everyone 
else either supports slicing or doesn't support multiple indices at all.  The 
semantics of Siop seeing a tuple sent to a subscript operator could be to 
make a two parameter call.  So in Python, you might write:


  remote_ruby_list[ (4,10) ] # Fetch list starting at 4 and going to 10

  Actually this syntax would work in Python, it so happens, as well (creates a 
tuple):

  remote_ruby_list[4,10] # Fetch list starting at 4 and going to 10

  Similarly, Java:

  remoteRubyList.get( new Integer{4,10} );

  To access a Hash which contains keys that are lists in Python, you would use 
lists:

  remote_ruby_hash[ [1,2,3] ] # Fetch item with key [1,2,3].

  Of course, Python would interpret accept list and tuples as parameters 
because it accepts either (whether or not your class can handle lists is 
another question).

  This would be a use for having an actual tuple for Ruby, although all those 
other languages still don't have a use for it.


> >   I think it makes sense for SIOP to have the notion of a Tuple type.
>
> Forgive my python ignorance, but what is a tuple and why would I want
> one?
>
> >From a brief glance at a couple python pages, it seems that a tuple is a
>
> readonly array. Is that really a useful thing? I can't actually think of
> any case in my life that I have wanted one.
>
> I guess the bigger question is whether you plan to support the cool
> extra feature of each language, or aim for more of a common subset.
>
> Kevin

Re: [Siop-development] How to implement the "Tuple" type in Python

[Rapheal K. <ra...@ma...>]

  I guess it's worth thinking about how many languages have an analogue for a 
Python Tuple.  I think I've only come up with Python, Java and C#.  What are 
the other set of languages out there and what are their Tuple analogs:

  Javascript - None
  Lisp - None
  Perl - None
  Groovy - Java Arrays
  C/C++ - Arrays, pointers
  D - Static arrays
  Php - None
  Bash - None
  OCAML - Tuples
  Smalltalk - None

  What else?

  I think Php is an interesting case because it will be tricky to distinguish 
between a list and a dictionary as it implements both the same way.

  Bash doesn't really have dynamic arrays, technically, it's all Tuples.

  Even though Tuples are now implemented, I am not necessary sold on keeping 
them in there.  However, I would like to think about straight forward 
solutions so that it is fairly easy to get static arrays and tuples to appear 
in places where they support it.

  I am ok with the idea that some constructs are only supported by subset of 
languages.  As long as each binding has a way of dealing with those 
constructs.  Again, Php is going to face this problem no matter what.

> >   I think it makes sense for SIOP to have the notion of a Tuple type.
>
> Forgive my python ignorance, but what is a tuple and why would I want
> one?
>
> >From a brief glance at a couple python pages, it seems that a tuple is a
>
> readonly array. Is that really a useful thing? I can't actually think of
> any case in my life that I have wanted one.
>
> I guess the bigger question is whether you plan to support the cool
> extra feature of each language, or aim for more of a common subset.

Re: [Siop-development] How to implement the "Tuple" type in Python

[Rapheal K. <ra...@ma...>]

> On Sat, 2006-06-17 at 18:33 -0700, Rapheal Kaplan wrote:
> >   I think it makes sense for SIOP to have the notion of a Tuple type.
>
> Forgive my python ignorance, but what is a tuple and why would I want
> one?
>
> >From a brief glance at a couple python pages, it seems that a tuple is a
>
> readonly array. Is that really a useful thing? I can't actually think of
> any case in my life that I have wanted one.
>
> I guess the bigger question is whether you plan to support the cool
> extra feature of each language, or aim for more of a common subset.
>

  This is a really good question and previously I had dwelled on whether or 
not to support it.  Fact is that many languages will have some sort of 
differentiation.

  Pythons reasoning for having tuples vs lists is relatively sound.  It has to 
do with the idea that hashable objects should be immutable.  So, for example, 
this means in Python you can't use a list as a key to a dictionary.  You can 
however, use a Tuple as a key to a dictionary.

  Ruby allows lists to be used as keys.

  In Java, a tuple would more likely fit in with an Array (I intend for 
java.util.List to map to the list type).

  This would also really means that immutability is not really a requirement 
for SIOP tuples so much as that they are statically sized lists.

  The idea would be to supply Ruby with the ability to explicitly create and 
handle tuples so that they can pass them to other programs.

  I think that not implementing Tuples in Ruby might be ok (as in, if it 
receives a Tuple instance it simply returns a list and doesn't care about 
it's original type).  However, there really does need to be a way for Ruby to 
indicate static sized arrays to a number of other programming languages. 
Again, maybe it could be handled in the casting Level rather than by 
implementing a Tuple object.

  Either way, the syntax in Ruby is not cumbersome.  You can work with lists 
all the way until you reach a method that requires it:


  my_list = [ 1,2,3,4 ]
  ... do stuff with list, make it bigger, etc...

  python_object.needs_a_tuple( Siop.Tuple(my_list) )

Re: [Siop-development] Send by reference or by value?

[Rapheal K. <ra...@ma...>]

> >   Question for folks... should the default mode of returning/sending
> > values from method calls be by reference or by value for abstract types?
>
> Speaking from a ruby standpoint, I think by-reference would be easiest
> and least surprising. In ruby, simple objects like integers are
> (conceptually) passed by reference...but they are immutable objects, so
> the effect is as if you had passed them by value.
>
> Speaking from an agile standpoint, I would be inclined to support only
> by-reference until a case came up that made it unworkable. At that
> point, a by_value wrapper would (hopefully) solve it.
>

  That was my thinking on it.  Integers and floats, however, will be passed by 
value.

  There is sort of already a use case, and as this is geared toward being 
compatible, it makes sense to support code where it requires an explicit 
certain type rather than just an interface.  This will certainly be the case 
for things like Java and it is already the case for the Python class 
structure, where the inheritence parameters require an actual tuple object.  
That's why in my example I use the Python tuple class to construct a tuple 
rather than just passing in a Ruby list which I would have definitely 
preferred to have done.

  But you are right, I am not going to rush it.  I think the next "Level" of 
SIOP should deal with these data typing/casting issues.

Re: [Siop-development] How to implement the "Tuple" type in Python

[Kevin S. <wx...@qu...>]

On Sat, 2006-06-17 at 18:33 -0700, Rapheal Kaplan wrote:
>   I think it makes sense for SIOP to have the notion of a Tuple type.  

Forgive my python ignorance, but what is a tuple and why would I want
one?

>From a brief glance at a couple python pages, it seems that a tuple is a
readonly array. Is that really a useful thing? I can't actually think of
any case in my life that I have wanted one.

I guess the bigger question is whether you plan to support the cool
extra feature of each language, or aim for more of a common subset.

Kevin

Re: [Siop-development] Send by reference or by value?

[Kevin S. <wx...@qu...>]

On Sat, 2006-06-17 at 17:05 -0700, Rapheal Kaplan wrote:
>   Question for folks... should the default mode of returning/sending values 
> from method calls be by reference or by value for abstract types?  

Speaking from a ruby standpoint, I think by-reference would be easiest
and least surprising. In ruby, simple objects like integers are
(conceptually) passed by reference...but they are immutable objects, so
the effect is as if you had passed them by value.

Speaking from an agile standpoint, I would be inclined to support only
by-reference until a case came up that made it unworkable. At that
point, a by_value wrapper would (hopefully) solve it.

Kevin

[Siop-development] How to implement the "Tuple" type in Python

[Rapheal K. <ra...@ma...>]

  I think it makes sense for SIOP to have the notion of a Tuple type.  It's 
obviously very straight forward for Python and maps relatively ok to Java 
array objects (vs. List objects).  This question is probably only answerable 
by Kevin, but does anyone have any idea what the best way to go about 
supporting Ruby Tuples are?  Right now, I've implemented a Tuple class, which 
is akin to an Array class, only it's immutable.

  Sort of needed to do it like that as creating an Array subclass bought me 
very little.  I needed to either make the array immediately frozen, or better 
yet, block the mutation methods.  However, that was not enough because all 
the different ways that lists operate often return NEW arrays.  However, for 
Tuples, it should really return new Tuples.

  Just wondering.  The Tuples in the SIOP Ruby library work.  However, if 
there is a better way, I would rather do that.

  - Rafe

[Siop-development] Send by reference or by value?

[Rapheal K. <ra...@ma...>]

  Question for folks... should the default mode of returning/sending values 
from method calls be by reference or by value for abstract types?  By 
reference would make for better network performance and would be closer to 
the way languages actually function, whereas by value would probably be 
better for compatibility.

  There is also a question of consistency.  Scalar values such as floats, 
integers and booleans always get sent by value by default.  So, if a function 
returns a boolean, SIOP will return to the client a boolean value for that 
platform rather than a reference to a boolean object.  However, as currently 
implemented non-scalar values, like lists and tuples are only returned by 
reference.  You need to make a call to "fetch-value" in order to have the 
server send a copy of those objects back to the client.

  When it comes to parameters, it should be possible to use simple object 
wrappers to indicate to the bridge to send objects by reference or value 
explicitly.  For example:

  remote_object.calculate_some_stuff( by_value( list_of_stuff ) )

  The function above might return another list of values.  Right now, this 
means that the client would receive a proxy that is a referenc to the list on 
the server.  If we changed the policy to be by default by value it a) makes 
the network traffic go up by default and b) makes it more difficult to keep 
the results of an operation on the server.

  Also how would we indicate how to return references by value or by 
reference?

  Maybe we could have by-reference proxies and by-value proxies.

  So, to explicity get the above reference by-value, you could do:

  value_proxy( remote_object ).calculate_some_stuff( list_of_stuff )

  All method calls to the value proxy could call a by value version of 
fetch-attribute and send-message instead of he default.

  Anybody care to venture thoughts?  Does any of this make sense?

  - Rafe

Re: [Siop-development] wxRython

[Rapheal K. <ra...@ma...>]

  Ok folks, as an example, I would like to introduce the first Python classes 
written in Ruby.  They look funny now, but once we get up to level 2, 
implement static arrays and maps, this will look a lot cleaner.  I'm thinking 
that it might even make sense for SIOP to have a level that deals with class 
definition.  I will put this in an example directory.

  Kevin, the code below actually works... when you resize the window the new 
size is printed to the console.  It's a fully Ruby based wx callback.  The 
trick turned out to be to use this weird "instancemethod" function.

  Anyway, see if you can figure out what it means...
-------------------------------
#!/usr/bin/env ruby

require 'siop/pipe'

Siop::Pipe.connect '../../scripts/siop-standard-server.py' do |bridge|
    bridge.fetch_namespace nil, 'wx'
    bridge.fetch_namespace nil, 'types'
    bridge.fetch_namespace nil, 'new'
    rc = bridge.remote_context
    wx = rc.wx
    instancemethod = rc.new.instancemethod
    $types = rc.types

    def tuple( *stuff  )
        list = $types.ListType.call
        for thing in stuff
            list.append( thing )
        end
        $types.TupleType( list )
    end

    def pyclass( name, parents, &definition )
        instance_eval do
            klass = $types.ClassType(   name.to_s,
                                    tuple( *parents ),
                                    $types.DictType.call
                                    )
            klass.instance_eval &definition unless definition.nil?
            klass
        end
    end

    MyApp = pyclass :MyApp, [wx.App] do
        self.OnInit = proc do | pyself |
            pyself.frame = MyFrame.call(nil, -1, "This is a test")
            MyFrame.Show( pyself.frame, true )
            pyself.SetTopWindow( pyself.frame )
            true
        end

        self.OnInit = instancemethod.call( self.OnInit, nil, self )
    end

    MyFrame = pyclass :MyFrame, [wx.Frame] do
        self.__init__ = proc do | pyself, parent, wid, title|
            wx.Frame.__init__( pyself, parent, wid, title )
            pyself.Bind( wx.EVT_SIZE, pyself.OnSize )
        end
        self.__init__ = instancemethod.call( self.__init__, nil, self )

        self.OnSize = proc do |pyself, event|
            p "Coordinates (#{event.GetSize.call.x}, #{event.GetSize.call.y})"
        end
        self.OnSize = instancemethod.call( self.__init__, nil, self )
    end


    app = MyApp.call


    app.MainLoop.call

end

Re: [Siop-development] SIOP FAQ

[Rapheal K. <ra...@ma...>]

  If you think wxWindows is not threaded then I should look in to it.  Maybe 
there is something I am missing.

> >   Of course... a windowing system IMMEDIATELY has threading issues.  The
> > call backs are coming in on a different thread, the results are returning
> > from the Python server out of order.  So, now there are threading issues.
>
> Hm. Odd. I don't recall seeing multiple threads in wxruby. Maybe
> wxpython is causing wx to be threaded "unnecessarily". Just a thought.
>
> The example is pretty cool, though. Maybe you could find a non-GUI
> library that's available in one language and not the the other. I don't
> have any ideas, though.
>
> Kevin

Re: [Siop-development] SIOP FAQ

[Kevin S. <wx...@qu...>]

On Sun, 2006-06-11 at 23:20 -0700, Rapheal Kaplan wrote:
>   Of course... a windowing system IMMEDIATELY has threading issues.  The call 
> backs are coming in on a different thread, the results are returning from the 
> Python server out of order.  So, now there are threading issues.

Hm. Odd. I don't recall seeing multiple threads in wxruby. Maybe
wxpython is causing wx to be threaded "unnecessarily". Just a thought.

The example is pretty cool, though. Maybe you could find a non-GUI
library that's available in one language and not the the other. I don't
have any ideas, though.

Kevin

Re: [Siop-development] SIOP FAQ

[Rapheal K. <ra...@ma...>]

>   I would like to see something like that happen.  So far, for some Python
> like reason, I am not able to hook up callbacks to wxWindows, although
> callbacks in general work over SIOP.  Maybe the wxPython has a wierd way of
> handling setattr.
>
>   This Ruby code works so far - When I figure a few more things out I will
> document it on the Wiki...
>


  Of course... a windowing system IMMEDIATELY has threading issues.  The call 
backs are coming in on a different thread, the results are returning from the 
Python server out of order.  So, now there are threading issues.

  I though about having each message pass through with a sort of call stack 
identifier.  As long as the transport itself is multi-threaded, it should be 
possible to have multiple threads with multiple call stacks using the bridge.

Re: [Siop-development] SIOP FAQ

[Rapheal K. <ra...@ma...>]

> >   Thanks a lot Kevin.  These are exactly the kind of things I need to
> > focus on.  I would like to make the example of Ruby using wx Windows,
> > but I don't want to diss your efforts on the wxRuby stuff.  I think I've
> > heard it from you, in addition to an out of date Ruby site, but is it
> > correct that wx support on Ruby is weak?
>
> Well, you could refer to "a GUI toolkit" rather than naming wx
> specifically. But I actually wouldn't mind if you did use it as an
> example. wxruby is "sort of working", but I haven't had the time to
> "finish" it, and no other developers have stepped up to take the lead.
>
> Hey, if there's an easier way to make wx available to ruby apps, I might
> jump ship. I'm skeptical about how easy it would be to wrap such a large
> library, to bridge a few python/ruby differences, and then to make it
> bearable to deploy ruby wx apps on all three major OS's.
>
> I'm intrigued.

  I would like to see something like that happen.  So far, for some Python 
like reason, I am not able to hook up callbacks to wxWindows, although 
callbacks in general work over SIOP.  Maybe the wxPython has a wierd way of 
handling setattr.

  This Ruby code works so far - When I figure a few more things out I will 
document it on the Wiki...

-------------------------------------------
#!/usr/bin/env ruby

require 'siop/pipe'

Siop::Pipe.connect '../../scripts/siop-standard-server.py' do |bridge|

    bridge.fetch_namespace nil, 'wx'
    wx = bridge.remote_context.wx

    app = wx.PySimpleApp(0)


    frame = wx.Frame( nil, -1, "This is a test" )

    frame.Show( true )

    app.SetTopWindow( frame )

    app.MainLoop.call

end

Re: [Siop-development] SIOP FAQ

[Kevin S. <wx...@qu...>]

On Sat, 2006-06-10 at 14:02 -0700, Rapheal Kaplan wrote:
>   I have posted a FAQ:
> 
> http://siop.net/wiki/index.php?pagename=SiopFaq
> 
>   Naturally, there is really only one question that people ask AT ALL, and the 
> page reflects it.  Naturally, this revision could use better wording.  How 
> does one explain what the hell this thing is?  For example, how do I explain 
> it to all of you??!?!!?

I think the explanation you have there is actually pretty good...but it
has a few gaps.

Mostly, how could this thing actually be used? It's funny, because I
actually really really wanted something exactly like SIOP a few years
ago...but now I can't remember why. I had found a similar project at
that time, but it was too immature, and the folks behind it seemed to be
a couple junior high tinkerers who had neither the knowledge nor the
follow-through to make it work.

So what are some examples of how someone might actually benefit from
this thing? Could I wrap wxpython and access it from a ruby app, instead
of creating wxruby? Could I write a ruby library for something like
statistics, and easily make it available to Python and Perl users? Or
would this be appropriate to create a web app where the web service part
runs as a separate process from the business logic part, even though
both are in Ruby?

An example is worth a million words.

Speaking of examples, a 5-line "server" and 5-line "client" would go a
long way toward showing what could be done. Something simple like a
getter on an object (employee.name).

A more detailed example might demonstrate the "key benefit" of SIOP over
CORBA and XMLRPC: automatic wrapping with no IDL declarations.

Probably as a separate Q/A: is the protocol binary or human-readable?
Although the answer doesn't really matter, it does speak to the
priorities of the project (speed vs. ease of debugging).

Kevin

[Siop-development] SIOP FAQ

[Rapheal K. <ra...@ma...>]

  I have posted a FAQ:

http://siop.net/wiki/index.php?pagename=SiopFaq

  Naturally, there is really only one question that people ask AT ALL, and the 
page reflects it.  Naturally, this revision could use better wording.  How 
does one explain what the hell this thing is?  For example, how do I explain 
it to all of you??!?!!?

[Siop-development] Who wants to look at the SIOP source code?

[Rapheal K. <ra...@ma...>]

  Folks who remember that they signed up to the siop-development mailing list,

  I have been going through something of an active development phase for SIOP 
lately.  I've been really happy with it.  If you all look at the wiki, you 
will see that there is something of a structure evolving from it.  I you 
check out the siop project from CVS, you can actually use the Ruby bindings 
to do... well it's not that useful by itself.

  In it's current state, you can create simple enterprise applications if you 
keep to a minimum your remote requests.  I wouldn't recommend it, of course, 
especially as there seem to be performance issues with SIOP running over 
sockets (the pipe based servers run nice and fast though).  You need to be 
prepared for that server to essentially run out of memory, of course, unless 
someone wants to implement the garbage collection mechanism.  This would 
consist of:

  1 - Implementing the "finalize" code for the proxy object.

  2 - Implementing the "release-reference" command.

  I know that nobody knows what I am talking about, but believe me, it makes 
sense.

  Otherwise, anyone up for a code review?  I know at least one of you is a 
right bastard about code criticism, and that kind of feedback is probably a 
good idea for now.

  - Rafe

[Siop-development] Anybody up for a code review?

[Rapheal K. <ra...@ma...>]

  Thanks to those who are on this list.

  SIOP development has ended up going really well since I switched to Ruby.  
It's a much better language for me as it has real theoretical objects in a 
way that I think Python sort of lacks.  This really helped get things jump 
started.

  For the most part, the over-all SIOP protocol structure is looking good... 
adding new commands and types as I have taken to calling things, is 
relatively easy, and it functions almost at Level 0 functionality.

  Level 0 functionality is what I am defining as the absolute minimum parts of 
the SIOP protocol required to excersize all of things that are capable to do 
with SIOP.  The levels above 0 are meant to further abstract the differences 
between different programming languages (for example, index based access to 
values, operator calling, etc.).

  If anyone is interested, feel free to do a code review of the Ruby code.  I 
am going to start to re-write the Python stuff, so don't even bother.  I know 
at least one of you can be a right bastard about doing reviews, and that's 
what is necessary.

  - Rafe