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
