orbit-python-list

Re: [Orbit-python-list] ORBit-Python Roadmap

[Roland M. <ma...@ec...>]

Jason Tackaberry (2001-05-25 15:32:44 -0400) :

> > Task taken here; will be showing progress over the weekend.
> 
> Great.  Make the test cases simple and focused.  For example, one
> client/server to test sequences, with a series of functions to test the
> various cases:

If you can both cool down a bit...  I found an old test-suite of mine
that pretty much fulfills these requirements.  It might not be
feature-complete yet, but it will probably provide a good starting
point.

  I'll rearrange it, and clean it a bit.  Then I will commit it to
CVS.  Tonight, probably.

Roland.
-- 
Roland Mas

C'est dans la boue la plus nauséeuse que plongent les racines de
l'étincelante fleur de lotus. -- in Sri Raoul le petit yogi (Gaudelette)

Re: [Orbit-python-list] ORBit-Python Roadmap

[Jason T. <ta...@li...>]

> I'd like to vote for pickling object references as a 0.4.0 feature, to be
> implemented in the first round of that.

That would make a reasonable 0.4.0 feature.  

> Task taken here; will be showing progress over the weekend.

Great.  Make the test cases simple and focused.  For example, one
client/server to test sequences, with a series of functions to test the
various cases:

interface SequenceTest {
	typedef sequence<long> seq;

	seq get_sequence(in long n);
	void set_sequence(in seq s);
	seq pass_sequence(in seq s);
};

The client should loop over each function individually 25000 or so
times.  My hope is that we can expand on these tests to identify memory
leaks and help in profiling.

> Can we target 0.3.0 for closing on June 1st, and release on the next week?

We can target all we want. :)

2 weeks might be enough, but then it might not.  I'll want to play it by
ear.  Remember I just committed a lot of hefty changes to the tree that
has the potential to break a lot of things.  If things are wishy washy
to begin with, I'll probably need more time to sort out the problems.

On the other hand, maybe I was in the zone last night and wrote solid,
bug free code.  Pfft, yeah right. :)

Jason.

Re: [Orbit-python-list] ORBit-Python Roadmap

[Christian R. R. <ki...@as...>]

On Fri, 25 May 2001, Jason Tackaberry wrote:

> object references were created from a type object.)  Objrefs now behave
> like real instances, so you can do things like objref.__class__.__dict__
> and it will behave as you'd expect.

I'd like to vote for pickling object references as a 0.4.0 feature, to be
implemented in the first round of that.

> Before 0.3.0 is released, these changes will have to stabilize and be
> tested.  Also planned for 0.3.0 is a comprehensive test suite, to
> validate and stress test _all_ of O-P.  I would also like to include a

Task taken here; will be showing progress over the weekend.

> So, that's the game plan.  You'll notice that no dates were attached to
> these versions.  That's because I have no clue. :)  I'd like to see

Can we target 0.3.0 for closing on June 1st, and release on the next week?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] ORBit-Python Roadmap

[Jason T. <ta...@li...>]

Over the last couple of months, ORBit-Python has received a considerable
amount of attention by myself and the other active developers and users.
Hacking has been steady, especially since the crew in #orbit-python
(OpenProjects Net) has been keeping me motivated. :)  There have been
some pretty interesting developments in the community, particularly
Johan Dahlin's work with OAF and Bonobo bindings.

I am especially curious to hear comments from people using O-P.  If
you're using it, have used it, or know someone that's using it, please
let me know how it held up.  Were there bugs that didn't get addressed?
Missing features?  Voice your opinions!

I've been mentally sketching out a roadmap for the next few versions.
Here are a few of my thoughts.  Comments welcomed.

--- snip ---

0.3.0
-----

Quite a bit has changed since 0.2.0 was released, and I'd like to get
0.3.0 out the door by next month.  Many areas have received more polish
and much closer spec compliance, especially with respect to system
exceptions, object references (implemented _is_a, _is_equivalent,
_hash_, _non_existent, _narrow), and the POA.

Some pretty large changes went in recently to make object references
actual class instances, derived from CORBA.Object.  (Originally all
object references were created from a type object.)  Objrefs now behave
like real instances, so you can do things like objref.__class__.__dict__
and it will behave as you'd expect.

Johan Dahlin's work has also involved creating an external ORBit-Python
API, similar to PyGtk's API.  This release should make the API useful.

Before 0.3.0 is released, these changes will have to stabilize and be
tested.  Also planned for 0.3.0 is a comprehensive test suite, to
validate and stress test _all_ of O-P.  I would also like to include a
number of small examples to compensate for the lack of decent
documentation.  Submissions graciously accepted. :)


0.4.0
-----

For 0.4.0, the ORBit module will be created, and all O-P proprietary
functionality will be put there (_load_idl(), for example).  It will
also let multiple ORBs coexist.  e.g.:

   from ORBit import CORBA
   import omniORB.CORBA

There are a few small features I have already planned, and those that
don't make it into 0.3.0 will be implemented for 0.4.0.

Any other medium to large changes or features that get requested will
likely be implemented for 0.4.0.  For this release, I want ORBit-Python
to be as spec-compliant as possible.


0.5.0
-----

This release will focus on performance and stability.  Performance is
already pretty good (still the fastest Python ORB that I'm aware of),
but some areas can be tightened and optimized.

Stability means _zero_ known bugs, and _zero_ known memory leaks.  I
will not release 0.5.0 with an unresolved bug or memory leak.  Some
memory leaks and bugs will be obviously addressed for 0.4.0, but for
those that are left, they will be closed for 0.5.0.  Period.

Basically, if 0.5.0 crashes or has problems, they're going to be
ORBit's. :)  That's the goal.  0.5.0 will be as close to production
quality as is possible.

--- snip ---

So, that's the game plan.  You'll notice that no dates were attached to
these versions.  That's because I have no clue. :)  I'd like to see
0.5.0 released by August, however.  It depends entirely on my own
schedule, and the amount of activity by the other developers.

Jason.

[Orbit-python-list] Using Sourceforge's Bug Interface

[Christian R. R. <ki...@as...>]

I'd like to call upon the orbit-python community to file bugs in
orbit-python to sf.net's bug interface properly. We've had assorted
hacking on the bindings the last months, and though the activity is great,
it would be nice to know what we're fixing and where we're going.

So please, if you've got a fix, or something to fix, do report a bug for
it first. I'll try and do likewise myself *grin*

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] Patch to handle non-Python Classes

[Christian R. R. <ki...@as...>]

Jason helped me hack this patch tonight that lets orbit-python handle
classes that inherit from non-Python classes (such as ExtensionClasses). I
use it specifically to allow us to make ZODB Persistent classes
ORBit-aware, and though ZODB doesn't work right, o-p at least now does
what it should.

The patch attached is full of comments, but it WorksForMe(tm) -- it's a
proof-of-concept that can be reviewed and integrated as desired.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] NameService howto?

[Christian R. R. <ki...@as...>]

On Thu, 17 May 2001, Frank Rehberger wrote:

> I dont understand how to connect to the nameservice of orbit.
> The following shows my code:

I assume here that you are running orbit-name-server, included in the
ORBit distro, yes?

> orb  = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)
> poa  = orb.resolve_initial_references("RootPOA")
> service = orb.resolve_initial_references("NameService")

Ah, your error lies here, and I'd like Tack to comment if he may.
Look, every CORBA-ized object publishes an object reference for itself. If
you have noticed, when you run o-n-s, it prints to stdout it's own IOR.

Now I think the standard facility for retrieving this is from etc/orbitrc
or ~/.orbitrc. Which means AFAICS that if you run the NameService, you
have to paste the IOR into that file. I know of no other way to do it, but
perhaps Eliott or somebody from orbit can help.

This is a definite problem, since you'll be running the nameservice with
interruptions, possible, which means you'll have to update the file in
realtime. I avoid doing that completely by going an orthogonal way: I
catch the nameserver reference from o-n-s and:

a) store it in a file in an nfs-shared directory, where clients can catch
it.

b) publish the reference through a webserver or whatever other means. I
personally created a tiny socket server and client that just spits the IOR
over.

Now my personal opinion is that's just plain annoying. But CORBA -- not
ORBit, I think, put perhaps it lacks a service (from what I grasp of it)
provides no standard mechanism to bootstrap the IOR, and that's evil. And
since GNOME publishes IOR in another fashion (using xprops, I think) it
doesn't bother them enough to implement some standard workaround :-)

> I would like to list the nameservice content.
> Who can help me?

I used to have some clients but I seem to have lost them. I'm attaching
the evil solution I use, so you can check it out. Please comment out the
part referring to the configfile as I don't really want to hack this right
now :-)

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] NameService howto?

[Frank R. <Fra...@we...>]

Hello,

I dont understand how to connect to the nameservice of orbit.
The following shows my code:
----------------------------------------------------
import sys, CORBA

CORBA._load_idl("/usr/share/idl/name-service.idl")

orb  = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)
poa  = orb.resolve_initial_references("RootPOA")
service = orb.resolve_initial_references("NameService")

print orb
print poa
print service

service.list(10, seq, iter)
---------------------------------------------------

The result was:

--------------------------------------
<CORBA.ORB object at 80d85b8>
<PortableServer.POA object at 80e0738>
None
Traceback (innermost last):
  File "./orbittool.py", line 13, in ?
    service.list(10, seq, iter)
AttributeError: 'None' object has no attribute 'list'
-------------------------------------

I would like to list the nameservice content. 
Who can help me?


cu, Frank

-- 
---------------------------------------------------
 Frank Rehberger <fre...@cs...>
---------------------------------------------------
 "Global order can arise from local interactions."
 [A.Turing, 1952]
---------------------------------------------------

Re: [Orbit-python-list] ORBit-Python 0.2.0 released

[Roland M. <lo...@de...>]

Jason Tackaberry (2001-04-03 00:29:29 -0400) :

> After a year of off-and-on development, I have finally released
> version 0.2.0.

For those of you out there running Debian...  I packaged and uploaded
this new version a few hours ago.  It should reach the "unstable"
distribution in another few hours, and "testing" in some days
(maybe).

Roland.
-- 
Roland Mas

C'est dans la boue la plus nauséeuse que plongent les racines de
l'étincelante fleur de lotus. -- in Sri Raoul le petit yogi (Gaudelette)

[Orbit-python-list] Re: [DO-SIG] Implementing proprietary extensions

[Martin v. L. <ma...@lo...>]

> Right now ORBit-Python implements a few extensions, such as transparent
> accessors (through __setattr__ and __getattr__).  These extensions don't
> really break the spec since they needn't be used at all.  However
> recently I've had a number of requests to implement coercion between
> CORBA.Any and Python objects.   This will obviously break the spec in
> the case of CORBA.Any return values.

You could offer accepting arbitrary values as in parameters, and
produce CORBA.Any objects for out parameters. This is probably what
most users want, since

  foo(Any(CORBA.typecode(MyStruct)), MyStruct(1,2,3))

is annoying, whereas

  r = foo().value
  print r.field

is acceptable, IMO.

As Duncan explains, you'll need to document what typecode ORBit infers
when it gets a Python object. That is relatively easy for the
primitive types, but can get involved for the constructed ones.

>     * strict: Enforce strict adherence to the mapping specification.
>       This will ensure compatibility with other specification-compliant
>       ORBs.

In particular, it will insure portability of applications. Strictly
conforming applications will also run in your extended mode; they just
won't use any extensions.

I wonder how many people would actually use the strictly conforming
mode. Most people will know when they deviate from the spec, and make
a choice whether that is acceptable. When porting applications, you'll
find problems even if you had been passing the strict mode: the spec
may have been interpreted in different way by implementors, or there
may be plain bugs or missing features in the implementations.

So the best way to achieve portability is to actually do the
porting. Then, the spec should be good enough to allow for portable
code in all applications.

>     * extended: a superset of the strict mode.  Features that extend the
>       specification, like transparent accessors or certain coercions,
>       become available.  This would be the default mode

Yes, that is what most CORBA implementations (in any language) provide.

> Any comments or thoughts on this approach?

As I've mentioned in another message: CORBA has its own policy
mechanism, which can be used to offer choices.

Regards,
Martin

[Orbit-python-list] Re: [DO-SIG] Implementing proprietary extensions

[Martin v. L. <ma...@lo...>]

> On Wednesday 11 April, Jason Tackaberry wrote:
> 
> > Right now ORBit-Python implements a few extensions, such as transparent
> > accessors (through __setattr__ and __getattr__).  These extensions don't
> > really break the spec since they needn't be used at all.  However
> > recently I've had a number of requests to implement coercion between
> > CORBA.Any and Python objects.   This will obviously break the spec in
> > the case of CORBA.Any return values.
> 
> Interesting. I can see how it's easy to return Python objects when
> unmarshalling an Any, but how would you do the marshalling side?  How
> can you tell if something like "hello" is meant to be a string or a
> sequence<octet>, or a sequence<char>, or a 5 element array of octet or
> char?

OTOH, looking at it from a compatibility perspective, allowing
additional (types for) values as parameters is an extension to the IDL
mapping, thus less troubling than returning the "unpacked" value.

> Personally, I don't think that's very nice at all. I don't like the
> __future__ thing either. I think it's confusing to re-use the import
> mechanism to do something altogether different.  I'd be inclined to go
> for something like
> 
>   import ORBit
>   ORBit.mapping_mode(ORBit.ENHANCED)
> 
> or perhaps
> 
>   ORBit.mapping_mode("enhanced")

Isn't that what policies are meant for? So I'd expect something like

 p = orb.create_policy(ORBit.ENHANCED)
 orb._set_policy_override([p],CORBA.ADD_OVERRIDE)

A specific function is easier to use, of course.

Regards,
Martin

[Orbit-python-list] Re: [DO-SIG] Implementing proprietary extensions

[Duncan G. <dg...@uk...>]

On Wednesday 11 April, Jason Tackaberry wrote:

> Right now ORBit-Python implements a few extensions, such as transparent
> accessors (through __setattr__ and __getattr__).  These extensions don't
> really break the spec since they needn't be used at all.  However
> recently I've had a number of requests to implement coercion between
> CORBA.Any and Python objects.   This will obviously break the spec in
> the case of CORBA.Any return values.

Interesting. I can see how it's easy to return Python objects when
unmarshalling an Any, but how would you do the marshalling side?  How
can you tell if something like "hello" is meant to be a string or a
sequence<octet>, or a sequence<char>, or a 5 element array of octet or
char?

> So I was wondering what the best approach would be to enable such
> proprietary enhancements in ORBit-Python.  I see 3 different "modes"
> that would change the way the module behaves:

The modes seem sensible to me.

[...]
>     from ORBit import enhanced
> or
>     from ORBit import strict
> 
> Any comments or thoughts on this approach?

Personally, I don't think that's very nice at all. I don't like the
__future__ thing either. I think it's confusing to re-use the import
mechanism to do something altogether different.  I'd be inclined to go
for something like

  import ORBit
  ORBit.mapping_mode(ORBit.ENHANCED)

or perhaps

  ORBit.mapping_mode("enhanced")


Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --

[Orbit-python-list] Implementing proprietary extensions

[Jason T. <ta...@li...>]

Right now ORBit-Python implements a few extensions, such as transparent
accessors (through __setattr__ and __getattr__).  These extensions don't
really break the spec since they needn't be used at all.  However
recently I've had a number of requests to implement coercion between
CORBA.Any and Python objects.   This will obviously break the spec in
the case of CORBA.Any return values.

So I was wondering what the best approach would be to enable such
proprietary enhancements in ORBit-Python.  I see 3 different "modes"
that would change the way the module behaves:

    * strict: Enforce strict adherence to the mapping specification.
      This will ensure compatibility with other specification-compliant
      ORBs.
    * extended: a superset of the strict mode.  Features that extend the
      specification, like transparent accessors or certain coercions,
      become available.  This would be the default mode
    * enhanced: features that break the spec become available, like
      coercing from CORBA.Any to Python objects.

The question becomes: what is the best way to select a mode?  In some
cases, the mode changes the actual semantics of the code.  Code between
enhanced and extended modes would work differently.  Python 2.1 uses a
__future__ module that is used to enable things like nested scopes.  My
inclination is to use a similar approach:

    from ORBit import enhanced

or

    from ORBit import strict

Any comments or thoughts on this approach?

Cheers,
Jason.

Re: [Orbit-python-list] ORBit-Python 0.2.0 released

[Christian R. R. <ki...@as...>]

On 4 Apr 2001, Jason Tackaberry wrote:

> So I can see 3 different modes: strict, which forces you to comply with
> the mapping spec; extended, which implements stuff like transparent
> accessors, type coercion where it doesn't break the spec; and enhanced,
> which implements all the fancy features we want.  (These names are up
> for debate.)

The names and theory are okay with me. 

> I'm mostly thinking aloud here.  Please everyone chime in with comments.
> Once I organize my thoughts a bit better I'll consult the gurus on
> Python do-sig and gather their input.

So how did they react to the idea?

> object._set_value(object._get_value() + 2) is a little uglier but also a
> little more explicit.  In some ways, it's more readable.  So it's not as
> if the accessor methods are pointless in the face of the transparent
> ones.  But I think the choice should be there for ORBit-Python because
> nothing is sacrificed by providing it.

After 2000 lines of _get_value and _set_value the transparent accessors
look nice, you know? :-)

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] Are you using ORBit-Python?

[Jason T. <ta...@li...>]

I'd like to add a section to the website that lists project that use
ORBit-Python.  So if you're using the library for any sort of project or
work that you're doing and want to be listed there, please let me know.

Cheers,
Jason.

Re: [Orbit-python-list] ORBit-Python 0.2.0 released

[Jason T. <ta...@li...>]

> It's good to see orbit-python back in action. For a while I've felt
> that omniORBpy is the only Python ORB going anywhere. Competition is
> good :-) .

That's definitely true, but right now I have a lot of catching up to do.
:)  Although at least ORBit-Python probably beats out the competition in
speed and memory usage.

> I've had a quick look at the web site, and I've spotted a couple of
> errors about the CORBA mapping...

I'm sure there are more ... ;)

> First, CORBA.ORB.shutdown() should take a boolean argument:

Oh right.  In fact my implementation requires it.  That's an error in
documentation.

> The POA._get_the_POAManager() function is part of the standard, not an
> omniORBpy specific thing. The POA's IDL definition contains:
> So the Python POA object has a _get_the_POAManager() function.

I have to admit I'm a little embarrassed about that. ;)  I never even
made the connection.  In my own defense, I've been using the transparent
accessors, so the _get_/_set_ accessors look a little foreign to me.

Thanks for pointing out these errors.  I'll make the corrections ASAP.

Regards,
Jason.

Re: [Orbit-python-list] ORBit-Python 0.2.0 released

[Duncan G. <dg...@uk...>]

On Thu 4 April, Jason Tackaberry wrote:

It's good to see orbit-python back in action. For a while I've felt
that omniORBpy is the only Python ORB going anywhere. Competition is
good :-) .

> The spec defines a base, so that all code written in compliance will be
> portable between any compliant implementation.  So this is a good thing.
> The trick is implementing extensions so they don't break the spec, and
> that making sure programmers who use the extensions know they're
> non-compliant.  This is one point that'll have to be worked out first.

Indeed. omniORBpy has quite a few extensions to the spec, and I'm in
the process of adding more. The difficulty is, as you say, making sure
that the extensions are clearly distinguished from the standard parts.
Wherever possible, I've put extensions in the omniORB package, so it's
obvious. Other times that's not possible, so I have to resort to
documentation.

If extensions become supported by several ORBs, it will be worth going
through the motions to add them to the official spec.


I've had a quick look at the web site, and I've spotted a couple of
errors about the CORBA mapping...

First, CORBA.ORB.shutdown() should take a boolean argument:

  module CORBA {
    interface ORB {   // PIDL
      ...
      void shutdown(in boolean wait_for_completion);
      ...
    };
  };

That omission might well be an omission in ORBit itself, rather than
just orbit-python.


The POA._get_the_POAManager() function is part of the standard, not an
omniORBpy specific thing. The POA's IDL definition contains:

  module PortableServer {
    ...
    interface POA {
      ...
      readonly attribute POAManager the_POAManager;
      ...
    };
  };

So the Python POA object has a _get_the_POAManager() function.

There are a few other minor things too. I recommend you download the
ORB interface and POA chapters of the CORBA spec and check all the
method signatures.


Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --

Re: [Orbit-python-list] ORBit-Python 0.2.0 released

[Jason T. <ta...@li...>]

> I believe the spec is important to a certain point, and beyond that, it's
> nonsense. The spec is there to guarantee portability between ORBs, but if
> you care very little about it, there's good reason to implement convenient
> mechanisms as options.

As you know, I'm not opposed to implementing extensions where they make
sense.  And the mapping spec certainly doesn't say implemenations can't
add their own extensions.  In fact, most of them do, I think.

The spec defines a base, so that all code written in compliance will be
portable between any compliant implementation.  So this is a good thing.
The trick is implementing extensions so they don't break the spec, and
that making sure programmers who use the extensions know they're
non-compliant.  This is one point that'll have to be worked out first.

> My personal opinion is that there should be a 'strict' mode and a 'o-p'
> mode, and implementing as far as it's possible both options in the
[...]
> to acheive the 'total' transparency feature. Python's dynamic nature is
> tied nicely to Any coercion, since you can really take advantage of the

Well, coercing Any is a little different than the transparent accessors.
With the transparent accessors you can use them, but you don't have to.
Your code works fine either way.  If you coerce _from_ Any to a Python
object (e.g. any myfoo() return the value itself instead of a CORBA.Any
object), then code that expects CORBA.Any will break. Coercing to Any
will work fine, mind you.

So I can see 3 different modes: strict, which forces you to comply with
the mapping spec; extended, which implements stuff like transparent
accessors, type coercion where it doesn't break the spec; and enhanced,
which implements all the fancy features we want.  (These names are up
for debate.)

"Extended" mode is a strict superset of "strict" mode, so that code
that's spec-compliant will work properly under Extended mode, but maybe
not vice versa.  "Enhanced" mode would contain stuff like coercion
_from_ CORBA.Any, where code that comes from another ORB _probably_
won't work without modification.  Extended mode would be the default.
The programmer can manually change the mode.  So if he wants to make
sure the code is easily portable to a different ORB, he'll turn on
"strict" mode.  ('course the interface to enable strict mode won't be
portable, but we can't have everything. :D)  If he wants to take
advantage of all the goodies, such as in your case, he'll enable
enhanced mode.

I'm mostly thinking aloud here.  Please everyone chime in with comments.
Once I organize my thoughts a bit better I'll consult the gurus on
Python do-sig and gather their input.

> flexibility types give us. And accessors.. well, do we really want to
> keep calling underscored methods? ;-)


Duncan Grisby gave some pretty compelling arguments in favor of using
the accessor functions in an email last August or September.  Basically
he said with:

   object.value = 1
   object.value = object.value + 2

By reading that code you'd assume object.value must be 3.  But it's
possible for the server implementation to override object._set_value (or
the __setattr__ method) to do something completely arbitrary.  It's also
possible for another client to modify object.value in between the first
two transparent method invocations.
object._set_value(object._get_value() + 2) is a little uglier but also a
little more explicit.  In some ways, it's more readable.  So it's not as
if the accessor methods are pointless in the face of the transparent
ones.  But I think the choice should be there for ORBit-Python because
nothing is sacrificed by providing it.

Jason.

Re: [Orbit-python-list] ORBit-Python 0.2.0 released

[Christian R. R. <ki...@as...>]

On 3 Apr 2001, Jason Tackaberry wrote:

> After a year of off-and-on development, I have finally released version
> 0.2.0.

And this is definitely news. Congratulations Jason, Roland, and everybody
else that worked on orbit-python during the period.

>    * Seamless Python <-> CORBA bindings
>    * Python mapping spec compliant
>
> These two goals often seem to work against each other.  For example, I
> want transparent accessor functions (i.e. obj.myint = 1 instead of
> obj._set_myint(1)), but the mapping spec requires that the accessor
> pairs be available.  O-P supports both approaches, but it should be made
> clear to the programmer that choosing the transparent accessors is going
> to result in non-compliant code.  I've also been considering coersion
> between CORBA.Any and Python objects, but this too would break the spec.
> These sorts of issues will need to be worked out; expect discussions
> here and on the Python dosig list.

I believe the spec is important to a certain point, and beyond that, it's
nonsense. The spec is there to guarantee portability between ORBs, but if
you care very little about it, there's good reason to implement convenient
mechanisms as options.

My personal opinion is that there should be a 'strict' mode and a 'o-p'
mode, and implementing as far as it's possible both options in the
codebase. I understand this does elevate complexity in the sense that
methods will have dual behaviour, but it's not undoable, and the benefits
are certainly important. The two points mentioned are very important, IMO:

- Transparent Accessors
- Any Coercion

to acheive the 'total' transparency feature. Python's dynamic nature is
tied nicely to Any coercion, since you can really take advantage of the
flexibility types give us. And accessors.. well, do we really want to
keep calling underscored methods? ;-)

AFAIC the spec is broken if it doesn't take into account these aspects. I
could, of course, be completely wrong.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] ORBit-Python 0.2.0 released

[Jason T. <ta...@li...>]

After a year of off-and-on development, I have finally released version
0.2.0.

Quite a bit has changed since the last release (0.1.3).  ORBit-Python
(and since I'm lazy, I've been starting to call it O-P for short) has
taken the dynamic IDL approach to another level by dynamically
preprocessing IDL modules and interfaces at load (import) time.  Now not
only is a separate IDL compilation step unnecessary, but in most cases
you also needn't specify _which_ IDL files need to be loaded.

With the new release comes a newly designed website
(http://orbit-python.sault.org/) where you can find the what might
actually resemble documentation.  Right now documentation is sparse, but
please suggest improvements and other topics.  I'd like to thank Roland
Mas, Christian Reis, and Johan Dahlin for helping out with testing, bug
reporting, suggestions, and so forth.  We have an IRC channel on the
OpenProjects Network called #orbit-python if you'd care to join in on
development discussions (although we mostly idle :)).

My original vision for ORBit-Python was _seamless_ bindings.  That is,
from the user's perspective, I wanted remote objects to work as close to
local Python objects as possible.  The Python mapping specification was
not formalized at the time I started the project, and so originally I
used it more as inspiration and guidelines than gospel.  Duncan Grisby
(omniORBpy) has since convinced me of the mapping spec's merits.  Since
0.1.3, quite a bit of work has been done to make O-P more compliant to
what is now the formalized Python mapping specification.  It's still not
perfect, but it's certainly come a long way since 0.1.3.

So, I can identify what I see to be my two main goals for ORBit-Python:

   * Seamless Python <-> CORBA bindings
   * Python mapping spec compliant

These two goals often seem to work against each other.  For example, I
want transparent accessor functions (i.e. obj.myint = 1 instead of
obj._set_myint(1)), but the mapping spec requires that the accessor
pairs be available.  O-P supports both approaches, but it should be made
clear to the programmer that choosing the transparent accessors is going
to result in non-compliant code.  I've also been considering coersion
between CORBA.Any and Python objects, but this too would break the spec.
These sorts of issues will need to be worked out; expect discussions
here and on the Python dosig list.

There are currently no known critical bugs with O-P, but there are a few
small memory leaks and some rough edges that need to be sorted out in
future versions.  As always, please report bugs and suggest
improvements.

Cheers,
Jason.

Re: [Orbit-python-list] Errors with the examples on web

[Jason T. <ta...@li...>]

> The client can be fixed by removing
> CORBA.load_idl("Account.idl")
> and adding
> import Bank

It sounds like you're using ORBit-Python from CVS and not 0.1.3.  The
CVS version will not handle the example on the website properly.  The
POA stuff in CVS is totally redone to adhere to the mapping spec.  Check
out the test-suite example for details, or ask on this list if you have
any other questions (since documentation is admitedly pretty scarce).
It should just be a matter of importing Bank and replacing POA.Bank to
Bank__POA.

Cheers,
Jason.

[Orbit-python-list] Errors with the examples on web

[Ruhi Bloodworth,,, <rbl...@db...>]

Hi,
I have tried running the example at http://projects.sault.org/orbit-python
The server part of the example gives me the following error
Traceback(innermost last):
    File "server.py", line 19, in ?
        servant = POA.Bank.Account(Account())
NameError: POA
The client part of the example gives me the following message
Traceback (innermost last):
    File "client.py", line 13, in ?
        except Bank.Account.InsufficientFUnds, data:
NameError: Bank

The client can be fixed by removing
CORBA.load_idl("Account.idl")
and adding
import Bank

I can send a modified version of the server if it would help
I am using
ORBit-Python 0.1.3
Orbit 0.4.91

Regards,
Ruhi Bloodworth

[Orbit-python-list] Re: Orbit-python-list -- confirmation of subscription -- request 485648

[damoga <da...@in...>]

----------  Mensaje Reenviado  ----------
Subject: Orbit-python-list -- confirmation of subscription -- request 485648
Date: Wed, 21 Feb 2001 10:17:35 -0800
From: orb...@li...
To: da...@in...


Orbit-python-list -- confirmation of subscription -- request 485648

We have received a request from 62.82.81.228 for subscription of your
email address, <da...@in...>, to the
orb...@li... mailing list.  To confirm the
request, please send a message to
orb...@li..., and either:

- maintain the subject line as is (the reply's additional "Re:" is
ok),

- or include the following line - and only the following line - in the
message body:

confirm 485648

(Simply sending a 'reply' to this message should work from most email
interfaces, since that usually leaves the subject line in the right
form.)

If you do not wish to subscribe to this list, please simply disregard
this message.  Send questions to
orb...@li....

-------------------------------------------------------

[Orbit-python-list] omniORB RPMS Available

[Rob R. <rr...@do...>]

Hello all,

I have just released a set of Red Hat 7.0 RPMS for omniORB and
omniORBpy.

omniORB is a very fast and efficient CORBA 2.3 compliant ORB. omniORBpy
are the Python bindings for omniORB. Both are released under a
combination
of GPL and LGPL licenses.

For more information and access to the RPMS, please see:
http://community.tummy.com/~rob/

-- 
Rob Riggs

[Orbit-python-list] Re: Exiting Corba Server app

[Elliot L. <so...@re...>]

On Thu, 15 Feb 2001, Christian Robottom Reis wrote:

> Hi, sorry for the crosspost but perhaps someone on the main list knows
> something I don't.
>
> I now wonder what's the proper way to shut down a corba application
> server? I'm using orbit-python, and I've noticed the following problem:
>
> I can't kill my server gracefully. I can't shut down my database
> connections, and I can't flush my files. Why?

Your app needs to call CORBA_ORB_shutdown (or orb.shutdown(), or whatever
the python bindings use). When your app makes that call is entirely Your
Problem.

-- Elliot
Who me? I just wander from room to room.