[omniORB] AMI and porting to Playstation

[Kevin Wooten]

Here's an update and omni related question!

First, we had drastically different requirements than omni provided, single
threading being the biggest, and size (we need it extremely small) being
another one. This, coupled with the licensing problem, caused me to write my
own ORB :( (I had NO idea). So I have spent the last two month's creating a
small, single threaded ORB that runs on the Playstation2 and Xbox. It is
modeled closely after omniORB, with regard to the transport system. I still
required AMI (w/o valuetypes), so the good news is I have STUDIED omni's
implementation and soon I hope to begin adding AMI to omniORB. I would like
to thank you Duncan, and all other contributors (ORL or otherwise), omniORB
is very well put together, and the source code is a breeze to comprehend!

I have been using omniORB to test compliance, and I have 85% of our ORB
working great. Although, occasionally I am seeing some intriguing responses
and I would like to check to see what is correct. I hope this is not a
bother.

My current concern has to do with _non_existent. First, I have an omniPy
client connect to my orb and make a remote call, then let it sit (not
disconnecting). Next, I reboot my ORB, causing the whole ip stack to be
rebooted. Finally, with the omni client I call _non_existent from the
reference. omniPy throws a "COMM_FAILURE_WaitingForReply", this appears to
be from the connection failing. If I then call _non_existent a second time
in a row, it reconnects to my orb and tries the call. At this time the
object no longer exists in my ORB and I throw the OBJECT_NOT_EXIST exception
back.

Is this correct? My understanding of the spec. is that _non_existent should
only throw an exception when the answer cannot be "reliably" determined. I
don't believe that a broken connection means this, after all connections
break all the time. I believe the reconnect should happen during the first
call, but I would like to hear your input.

Thanks,
Kevin Wooten

-----Original Message-----
From: Duncan Grisby [mailto:duncan at grisby.org] 
Sent: Monday, November 24, 2003 4:12 PM
To: Kevin Wooten
Cc: 'omniorb-list at omniorb-support.com'
Subject: Re: [omniORB] AMI and porting to Playstation 

On Monday 24 November, Kevin Wooten wrote:

> I am in the middle of porting omniORB to the Playstation 2, I don't mean
> Linux on the Playstation, I mean using the raw kernel, which is the
problem.
> I thought about the licensing and realized it precludes me from doing
this!!
> I cannot provide the source code to the public domain, as much as I would
> love to. This is mostly a Sony issue, in that I am not allowed under any
> circumstances to provide information to non-licensed developers about SDK
> information. I am just checking to see if there is a way around this or
not?
> So far I have reworked the threading and sockets to start to get it
working
> (I hope that isn't too much information). Is there any way around this? Or
> should I move on to creating my own (much less amazing) ORB?

Well, I am not a lawyer, so this is all just my opinion. Also,
although some of the copyright to omniORB belongs to me or companies I
have control over, the majority of it is owned by "AT&T Laboratories
Cambridge Ltd". That company no longer exists, so I don't know exactly
who owns the copyright. It is safe to assume that it is probably owned
by AT&T. Basically, that means there is not much hope of changing the
license of omniORB.

So, the question is whether you can proceed while staying within the
terms of the LGPL. Obviously, the ideal situation would be for you to
release your modifications under the LGPL, but if Sony won't permit
that, there may be other options. First, omnithread is a pretty simple
API. It shouldn't be too hard to implement all of it without using any
code from the existing implementations. An independent implementation
of the omnithread API would definitely not be a derived work of
omnithread, so you would be free to use that without restriction.

For the other things, the situation is rather more tricky. I _think_
it would be acceptable under the LGPL for you to define an API
encapsulating the Playstation specific code, and modify omniORB to use
that API. The LGPL terms would require you to release those
modifications to omniORB. However, you would not, I believe, have to
release the implementation of the API. That would especially be true
if you could arrange for the API implementation to be a dynamically
linked library (I don't know if the Playstation has such things).

I hope that helps, but please don't hold me responsible for any
consequences...

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --