Hi Anton, I was thinking about the cases where a client would work with default domain and all related domains from it. I think we should provide something there. But since that's a bit more effort, I thought I do it in a second step.
Hope that's fine with you. For that step we have to discuss a bit how the output shall look like. Domains can overlap. How would we present that to the user? Cheers, Uli > -----Original Message----- > From: ext Anton Pak [mailto:[email protected]] > Sent: Tuesday, June 08, 2010 2:21 PM > To: [email protected] > Subject: Re: [Openhpi-devel] Domain Support for Clients > > Uli, > > Seems I missed one thing about -D parameter for HPI clients. > When domain id is not specified there are two ways > - work with default domain > - work with default domain and all domains accessible from > default domain. > > Which way you bear in your mind? > > Anton Pak > > > On Tue, 08 Jun 2010 16:12:28 +0400, Anton Pak > <[email protected]> > wrote: > > > Uli, > > > > Well, not sure we can break it. > > However it is pretty looking architecture solution. > > Let's make a voting! :) > > > > As for default domain id, I suggest to make a number that > helps to avoid > > collision. > > I hope implementors using reasonable numbers in their HPI > implementation. > > > > As for peer domains, not sure there are men liking to have it > > implemented. > > What is the NSN position for peer domains? > > > > > > Anton Pak > > > > On Tue, 08 Jun 2010 15:04:39 +0400, Kleber, Ulrich (NSN - > DE/Munich) > > <[email protected]> wrote: > > > >> Hi Anton, > >> see answers inline. > >> > >> Cheers, > >> Uli > >> > >> > >>> -----Original Message----- > >>> From: ext [email protected] > >>> [mailto:[email protected]] > >>> Sent: Tuesday, June 08, 2010 11:56 AM > >>> To: [email protected] > >>> Subject: Re: [Openhpi-devel] Domain Support for Clients > >>> > >>> Uli, > >>> > >>> Your cases 1,2,3 looks good. > >>> > >>> The alternative way is to provide default domain in any case. > >>> Just empty domain and DRT referring to domains from > >>> openhpiclient.conf. > >>> It will be simplier to implement and architecture will be > more clear. > >> > >> So you mean the openSession(SAHPI_UNSPECIFIED_DOMAIN_ID) > in all cases > >> has no resources, but only DRT. > >> I agree, and even would prefer it. > >> But I expect the typical user today when having only 1 domain with > >> empty openhpiclient.conf (so daemon on localhost:4743), > will use that > >> coding. So my proposal was already a compromise for client > >> compatibility. > >> If you think we can break that, I would prefer your alternative. > >> > >>> > >>> However, I have no strong preference to any of these two ways. > >>> > >>> May be we shall use well-known (non zero) DomainId for the > >>> User Library Default Domain. Say 42 for example? :) > >>> For the domain we may have: > >>> - SaHpiDomainInfo.DatUserAlarmLimit = 0; (Argh! 0 means no > >>> limit according > >>> to Sahpi.h) > >>> - SaHpiEventLogInfoT.Size = 0 > >>> - Empty SaHpiEventLogCapabilitiesT > >>> - some tricks with saHpiEventGet/saHpiEventAdd, added event shall > >>> appear at any session event queue. > >>> > >> > >> I think the zero DomainId is fine for that - even if we > created some > >> default characteristics that are not optimal. > >> But if we create another value, I don't think it should be > the answer > >> on all of our questions :), may be 0x80000000? > >> But do we really need that? > >> > >> > >>> > Then why is it defined in the openhpiclient.conf? Shouldn't all > >>> > infos that the daemon needs be to know be defined in > openhpi.conf? > >>> > >>> I think only the Daemon Domain Id is ok for openhpi.conf. > >>> Currently any daemon just provides domain 0. > >> > >> Right. Today the daemon doesn't need to know. > >> But if we introduce peer domains in OpenHPI 2.42, it might > need to know. > >> I am fine with not changing that for now. > >> > >> > >>> > >>> > Why would we need to have multiple domains with the > same host:port? > >>> > I think OpenHPI's idea to have a daemon implementing > >>> exactly one domain > >>> > is a nice principle. > >>> > >>> Well, 2.8 and 2.10 had multiple domain support on daemon level. > >>> openhpiclient.conf is 2.12 innovation. > >> > >> OK. > >> I don't know about history. > >> > >>> > >>> I know two more HPI implementation that may be used with > >>> OpenHPI client > >>> library. PPS has one of them. > >>> The domain architecture for another HPI implementation may be > >>> different. > >>> I don't think we shall shut the door for other HPI > implementations. > >>> Such scalability is one of OpenHPI strenghtes. > >> > >> I fully agree. > >> > >> Cheers, > >> Uli > >> > >>> > >>> Anton Pak > >>> > >>> > Hi Anton, > >>> > > >>> > see some comments inline. > >>> > Sorry for the confusion with the thought experiment. > >>> > > >>> > I read again what the spec says about the default > domain and I also > >>> > remember a speech by DavidM, that the default domain is > not a real > >>> > domain. > >>> > The default domain is accessed via SAHPI_UNSPECIFIED_DOMAIN_ID, > >>> > which is 0xFFFFFFFF. > >>> > > >>> > The spec says on p.28: > >>> > 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. > >>> > When a domain is accessed with SAHPI_UNSPECIFIED_DOMAIN_ID, the > >>> > actual domain identifier associated with the domain may > be obtained > >>> > from the DomainInfo structure returned by the > saHpiDomainInfoGet() > >>> > function. > >>> > > >>> > So I think that's what we should provide: > >>> > > >>> > Case 1, when openhpiclient.conf defines no domain: > >>> > > >>> > - When the user opens a session with > >>> > domain-id=SAHPI_UNSPECIFIED_DOMAIN_ID, > >>> > we open the session with the default daemon (localhost:4743). > >>> > - When the user calls saHpiDomainInfoGet() we provide > domain-id 0. > >>> > - When the user opens a session with domain-id=0, the > same happens. > >>> > - When the user tries to access another domain, we return > >>> > SA_ERR_HPI_INVALID_DOMAIN > >>> > > >>> > > >>> > Case 2, when openhpiclient.conf defines one single > domain (let's use > >>> > id=1): > >>> > > >>> > - When the user opens a session with > >>> > domain-id=SAHPI_UNSPECIFIED_DOMAIN_ID, > >>> > we call the daemon as defined for domain-id 1 > >>> > - When the user calls saHpiDomainInfoGet() we provide > domain-id 1. > >>> > - When the user opens a session with domain-id=1, the > same happens. > >>> > - When the user tries to access another domain, we return > >>> > SA_ERR_HPI_INVALID_DOMAIN > >>> > > >>> > > >>> > Case 3, when openhpiclient.conf defines multiplee > domains (for the > >>> > example > >>> > let's use two domains id 1 and 2) > >>> > > >>> > - When the user opens a session with > >>> > domain-id=SAHPI_UNSPECIFIED_DOMAIN_ID, > >>> > we don't call a daemon. > >>> > - When the user calls saHpiDomainInfoGet() we provide > domain-id 0. > >>> > But there are no resources. Maybe even events are not > >>> needed (there > >>> > could be > >>> > events with type domain. But we don't change the set of > >>> domains that > >>> > are > >>> > defined - that is are on DRT of default domain, so we > >>> will never issue > >>> > such > >>> > event) > >>> > - The user should call saHpiDrtEntryGet() in this session > >>> to read which > >>> > domains > >>> > are defined. > >>> > We don't implement peer domains, so all domains are > >>> "related non-peer > >>> > domains" > >>> > as described on p.26. > >>> > - The user then should open sessions with domains 1 and 2. > >>> And work with > >>> > them. > >>> > - I think the DRT of domain 1 and 2 can still be empty. > >>> > > >>> > Currently we have defined domain 0 in all cases, always > fixed to the > >>> > daemon > >>> > localhost:4743. This behavior is ok for all cases. If > >>> somebody doesn't > >>> > like > >>> > that domain, he can avoid starting that daemon and use a > >>> different port. > >>> > > >>> > > >>> > Is this the behavior we need in a first step? > >>> > When we agree on that we can start to discuss how we > >>> implement it in our > >>> > > >>> > architecture. > >>> > In later steps, real domains could have related non-peer > >>> domains, and in > >>> > later > >>> > future we could go to peer domains. > >>> > > >>> > > >> > >> ... snip > >> deleted old stuff. > >> > >> > >> > >> > -------------------------------------------------------------- > ---------------- > >> ThinkGeek and WIRED's GeekDad team up for the Ultimate > >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > >> lucky parental unit. See the prize list and enter to win: > >> http://p.sf.net/sfu/thinkgeek-promo > >> _______________________________________________ > >> Openhpi-devel mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/openhpi-devel > > > -------------------------------------------------------------- > ---------------- > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Openhpi-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openhpi-devel > ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Openhpi-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openhpi-devel
