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. 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. 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? Currently saHpiDrtEntryGet cannot find something in the drt's because with OpenHPI daemons they are always empty. - I agree that domains of the library are unrelated. - 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. - How may beers for the bargain? ;-) 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
