Issue 4368: Need a cleaner and more efficient way of retrieving current versions of Org (osf-ftf)
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Revision
Severity: Significant
Summary: :  In order to discover information 'as of' a certain date, it is suggested (p121 of convenience document) that the client go through the hassle of trawling through the entire version history and filtering out the correct timespan to get an ID and then performing a lookup by ID. This is painful enough for one object. However this also 'infects' interfaces such as OrgModel::list_orgstructures which will presumably return *all* OrgStructures for the model regardless of how old/retired/expired they are. And one will have to trawl the version history of each of these.  So this means that each Orgstruct that has ever existed in the model will need to be returned to the client just to get the current ones. And all this information is being returned across 'the wire' rather than being filtered within the OSF Facility. [According to the spec it is purely up to the client to interpret effective/expired dates and the Facility will perform no filtering at all based on these timestamps].
Resolution: 
Revised Text: 
Actions taken:
June 20, 2001: received issue
Discussion: 
Need a cleaner and more efficient way of retrieving current versions of OrgStructures
End of Annotations:=====
Issue:  Need a cleaner and more efficient way of retrieving current
versions of OrgStructures
Source:  Adaptive Ltd. (Mr. Pete Rivett, pete.rivett@adaptive.com)
Nature:  Revision
Severity:  Significant
Summary:  In order to discover information 'as of' a certain date, it
is suggested (p121 of convenience document) that the client go through
the hassle of trawling through the entire version history and
filtering out the correct timespan to get an ID and then performing a
lookup by ID. This is painful enough for one object. However this also
'infects' interfaces such as OrgModel::list_orgstructures which will
presumably return *all* OrgStructures for the model regardless of how
old/retired/expired they are. And one will have to trawl the version
history of each of these.  So this means that each Orgstruct that has
ever existed in the model will need to be returned to the client just
to get the current ones. And all this information is being returned
across 'the wire' rather than being filtered within the OSF
Facility. [According to the spec it is purely up to the client to
interpret effective/expired dates and the Facility will perform no
filtering at all based on these timestamps].
Resolution:
Revised Text:
Actions taken: