My comments inline.
Anton Pak
On Mon, 18 Oct 2010 14:05:05 +0400, Kleber, Ulrich (NSN - DE/Munich)
<[email protected]> wrote:
> Hi Anton,
> I think the domain x command in hpi_shell is fine that way and I
> agree with most of your comments below.
> A few questions remain open for me:
>
> - drt command:
> Already today, the hpidomain client uses saHpiDrtEntryGet to display
> the drt. May be we should extend hpi_shell to do the same.
"domain" command without parameters also displays DRT for the current
domain.
So the DRT code is already present in hpi_shell.
> We could introduce oHpiDomainList function or oHpiDomainGet or similar
> function that walks the actual list of domains know by baselib.
> That way there would be no compatibility issues.
Yes, makes sense for me.
> Would you prefer that instead of my original proposal to have
> saHpiDrtEntryGet(OH_DEFAULT_DOMAIN_ID) display DRT of OpenHPI default
> domain
> and saHpiDrtEntryGet(SAHPI_UNSPECIFIED_DOMAIN_ID) display what baselib
> knows?
> Do you see other compatibility issues?
I find it rather tricky.
saHpiDrtEntryGet has no domain id parameter.
So you would need to open session to OH_DEFAULT_DOMAIN_ID or
SAHPI_UNSPECIFIED_DOMAIN_ID before.
> Currently saHpiDrtEntryGet cannot find something in the drt's because
> with
> OpenHPI daemons they are always empty.
True for now.
I believe it will change sometimes.
>
> - I agree that domains of the library are unrelated.
Well, openhpiclient.conf may define a domain for OpenHPI daemon connected
to
Shelf Manager and may define a domain for OpenHPI deamon running on a
Board Payload.
Who would say the domains are unrelated if the Board is under the Shelf
Manager control?
> - What is our expected behavior of the library if a session to the
> default domain
> cannot be opened? I think it still should be possible to retrieve the
> domain
> list somehow.
> If we provide oHpiDomainList/oHpiDomainGet function, this would be
> possible,
> since it would work outside sessions.
Cannot say now.
May be it shall try to open session to any available domain defined in
openhpiclient.conf.
>
> - How may beers for the bargain? ;-)
$1M in $100 bank notes packed in opaque case. :)
>
> Cheers,
> Uli
>
>
>> -----Original Message-----
>> From: ext Anton Pak [mailto:[email protected]]
>> Sent: Tuesday, October 05, 2010 1:18 PM
>> To: [email protected]
>> Subject: Re: [Openhpi-devel] Observation with missing domain 0
>>
>> 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
>>
>
> ------------------------------------------------------------------------------
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> _______________________________________________
> Openhpi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
