[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [Fwd: RE: on the issue of PartyId]
DW, Glad there's someone other than me worrying about efficiency. However, I would suggest that there's no such thing as a "very high performance query" -- the number of messages sent is the same for a query as for a fetch and the number of disk accesses is probably identical (today's transmission speed say that the few extra bytes sent don't count for much). The big things for efficiency are (a) number of messages, (b) disk access time, and (c) contect switches. Your 90+% sounds about right (if not a bit low), but you're getting into caching policy which I don't know much about. Who keeps the cache -- app or service provider? Who decides the policy, ebXML for a standardized policy, vendor/implementors, app's themselves? How often and when is refresh done -- on demand or during idle time? Host of questions (and headaches unless we throw it over the wall ;-) Best regards, Henry ---------------------------- At 01:02 PM 09/22/2000 -0400, you wrote: >Message text written by Henry Lowe >>For effiency reasons, you don't want to force all TRP MS message >sent to include an access to a respository -- if you do, ebXML >will be a PIG and we will be just another footnote in IT history. >Bandwidth is cheap, but remote accesses ain't!! > >Best regards, >Henry< > >>>>>>>>>>>>> > >Henry, > >I raised this issue this week in RegRep - the ability to >locally cache and to have a very high performance query >to check if content has changed since last query. > >Clearly machine-2-machine accesses to the registry >will be 99% of what is does - and we know from earlier >registries that 90%+ of content never changes once it >reaches 'approved' status. > >This then also leads into distributed registries too, but >that's definately RegReps bag to sort out.... > >DW.
Powered by eList eXpress LLC