[omniORB] FW: Problem w/ Client/Server Communication Across L AN With Client /Server NameServices

Thu Oct 17 16:23:00 2002

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C275F0.EAA3F650
Content-Type: text/plain;
	charset="iso-8859-1"

So the only way I can get the IOR I need is to rebuild omniORB and get the
string 
on the initial omniNames startup?

Wayne Smith
wsmith@btg.com
410-286-9762

-----Original Message-----
From: bjorn rohde jensen [mailto:bjensen@fastmail.fm]
Sent: Wednesday, October 16, 2002 12:54 PM
To: Smith, Wayne
Cc: 'omniorb-list@omniorb-support.com'
Subject: Re: [omniORB] FW: Problem w/ Client/Server Communication Across
L AN With Client /Server NameServices

Hi Wayne,

  After having looked at the omniORB 2.8.0 omniNames on
SourceForge i realise, i have assumed quite a bit too
much about it....
  I think, you are entirely correct, that omniNames v280
does indeed generate a unique objectKey each time, it is
started using the start option, but as far as i can tell,
it should reuse the objectKey there after. The only way,
you appear to be able to reach that version of omniNames
is through the IOR, it dumps on startup. If you distribute
the IOR generated, when omniNames is started for the first
time, and there after let omniNames bootstrap from its log,
things ought to work well enough.
  All this would be a lot easier, if you were not using
a 3-4 years old version....

Yours sincerely,

Bjorn

------_=_NextPart_001_01C275F0.EAA3F650
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: [omniORB] FW: Problem w/ Client/Server Communication Across L AN With Client /Server NameServices</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>So the only way I can get the IOR I need is to rebuild omniORB and get the string </FONT>
<BR><FONT SIZE=2>on the initial omniNames startup?</FONT>
</P>

<P><FONT SIZE=2>Wayne Smith</FONT>
<BR><FONT SIZE=2>wsmith@btg.com</FONT>
<BR><FONT SIZE=2>410-286-9762</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: bjorn rohde jensen [<A HREF="mailto:bjensen@fastmail.fm">mailto:bjensen@fastmail.fm</A>]</FONT>
<BR><FONT SIZE=2>Sent: Wednesday, October 16, 2002 12:54 PM</FONT>
<BR><FONT SIZE=2>To: Smith, Wayne</FONT>
<BR><FONT SIZE=2>Cc: 'omniorb-list@omniorb-support.com'</FONT>
<BR><FONT SIZE=2>Subject: Re: [omniORB] FW: Problem w/ Client/Server Communication Across</FONT>
<BR><FONT SIZE=2>L AN With Client /Server NameServices</FONT>
</P>
<BR>

<P><FONT SIZE=2>Hi Wayne,</FONT>
</P>

&nbsp; After having looked at the omniORB 2.8.0 omniNames on
 SourceForge i realise, i have assumed quite a bit too
 much about it....
 &nbsp; I think, you are entirely correct, that omniNames v280
 does indeed generate a unique objectKey each time, it is
 started using the start option, but as far as i can tell,
 it should reuse the objectKey there after. The only way,
 you appear to be able to reach that version of omniNames
 is through the IOR, it dumps on startup. If you distribute
 the IOR generated, when omniNames is started for the first
 time, and there after let omniNames bootstrap from its log,
 things ought to work well enough.
 &nbsp; All this would be a lot easier, if you were not using
 a 3-4 years old version....

<P><FONT SIZE=2>Yours sincerely,</FONT>
</P>

<P><FONT SIZE=2>Bjorn</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C275F0.EAA3F650--