Uli,
I am thinking about removing domain listing option for "domain" command
(when it is invoked without params).
Now it just lists DRT for current domain.
I feel it is better to introduce "drt" command and may be
"list_all_domains_that_baselib_knows_about" command.
See more comments inline.
Anton Pak
On Tue, 05 Oct 2010 13:14:47 +0400, Kleber, Ulrich (NSN - DE/Munich)
<[email protected]> wrote:
> Hi,
> I am testing OpenHPI is multi domain environment.
>
> So I work with openhpiclient.conf defining some domains with id != 0,
> that are served by daemons on other machines.
> OpenHPI base library automatically creates a domain 0 with daemon on
> localhost:4743. But if that daemon is not running (or a defined domain 0
> serving daemon is not running), we have the following behavior:
> - Sessions can be opened to all domains where daemons are running (OK)
> - Sessions to domain 0 cannot be opened (OK)
> - Session to domain SAHPI_UNSPECIFIED_DOMAIN_ID cannot be opened (not
> OK?)
> P.28 in the spec, chapter 3.2.3, first paragraph somehow suggests that
> the HPI implementation should select a domain id that can open a
> session.
Well.
I think we fulfill the req:
-----------------
Which domain is accessed when SAHPI_UNSPECIFIED_DOMAIN_ID is used is
implementation-specific, and may be different for different HPI Users.
-----------------
But there is definitely an issue with:
-----------------
To support the general discovery process described in Section 3.5, HPI
implementations should ensure that all the domains that a user needs to
access are related and are discoverable from the default domain returned
when the user opens a session specifying SAHPI_UNSPECIFIED_DOMAIN_ID.
-----------------
I like the idea of having artificial empty default domain with DRT only on
library level.
But there would be strong objections against due to compatibility with
previous OpenHPI versions.
> But it is hard to say which of the openhpiclient.conf entries should
> be
> selected.
> - hpi clients without -D parameter return NO_RESPONSE (OK)
> - hpi_shell returns NO_RESPONSE (not OK, since currently there is no way
> to
> start hpi_shell and then change domain, Anton is currently adding an
> option for that)
Yep.
> - There is no API to determine which domains are defined, except reading
> the
> openhpiclient.conf file.
> - Even if there would be DRT entries, there is no way to read them,
> since no session to default domain can be opened.
I am fine with it if the domains are considered as unrelated.
> - After domains are created using oHpiDomainAdd (feature 3064532), those
> domain ids cannot be retrieved by an API. Somehow we need to implement
> feature 3025777.
When we reach an agreement or make a bargain. :)
>
>
> Comments?
> Cheers,
> Uli
>
>
>
>> -----Original Message-----
>> From: ext Anton Pak [mailto:[email protected]]
>> Sent: Monday, October 04, 2010 5:26 PM
>> To: Kleber, Ulrich (NSN - DE/Munich)
>> Subject: Re: support for oHpiDomainAdd and oHpiDomainAddById
>> in hpi_shell
>>
>> Uli,
>>
>> Thanks!
>> I get your point and start thinking about removing the second part of
>> new domain functionality - switching to new domain.
>> So the "newdomain" command shall be followed with "domain
>> <id>" command
>>
>> As for domain 0, HPI implementation shall always provide it.
>> May be your observations add some weight
>> to Artificial Default Domain on Base Library Level idea.
>>
>> What say?
>>
>> My plan is to wait 3 days after final patch publication and
>> then proceed
>> with it.
>> Bryan's Sutula Rule :)
>>
>> Anton Pak
>>
>> On Mon, 04 Oct 2010 19:18:41 +0400, Kleber, Ulrich (NSN - DE/Munich)
>> <[email protected]> wrote:
>>
>> > Hi Anton,
>> > works fine for me!
>> > I also like the way, the syntax and the interactive paramter request
>> > work.
>> >
>> > Two observations during my test:
>> > - We (oHpiDomainAdd) allow only to add a domain that is
>> already active.
>> > That is: If there is no daemon running at the specified host:port,
>> > the domain is rejected. This is different to openhpiclient.conf, I
>> > think.
>> > There the domains are defined and as long as nobody tries to open
>> > a session, nobody notices.
>> > - hpi_shell doesn't start if the domain 0 is not available.
>> > I tried openhpiclient.conf with just one domain on a
>> different host,
>> > while
>> > the daemon on localhost was not running. I get NO_RESPONSE from
>> > session open.
>> > So hpi_shell always tries to open domain 0 - even when no
>> domain 0 is
>> > defined
>> > in openhpiclient.conf.
>> >
>> > Those observations don't affect your patch.
>> >
>> > When can we go forward committing more stuff?
>> >
>> > Cheers,
>> > Uli
>> >
>> >
>> >> -----Original Message-----
>> >> From: ext Anton Pak [mailto:[email protected]]
>> >> Sent: Monday, October 04, 2010 3:50 PM
>> >> To: Kleber, Ulrich (NSN - DE/Munich)
>> >> Subject: support for oHpiDomainAdd and oHpiDomainAddById
>> in hpi_shell
>> >>
>> >> Hello!
>> >>
>> >> Just have uploaded a patch for this feature to SF tracker.
>> >> Could you by any chance try it?
>> >>
>> >> Anton Pak
>> >>
>> >>
>>
>>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
> Spend less time writing and rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Openhpi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
