Allow BPPs to explicitly allow caching when required for a specified period

[ravi-prakash-v]

To enable search optimization on beckn-enabled networks, it has been observed that BAPs tend to cache BPP catalogs to maintain low request-response TAT. Some BAPs have expected request-response TATs as low as 200 ms.

Currently a typical open search across the network goes via a BG, to multiple BPPs, back to BGs and ultimately back to the BAPs. In such cases, the TAT has been observed to range from 2s to almost 10s which is unacceptable as per industry standards. As a results, BAPs have no choice but to cache catalogs to allow faster response times.

Currently, the catalogs published by BPPs do not have a choice to explicitly "allow" caching of their catalogs at the BAPs.

hence I propose that a new attribute - allow_caching be added to schemas like Catalog, Provider, Category, Item, Offer, and AddOn. Maybe even to other schemas like Payment, Fulfillment etc.

However, caching must also come with a constraint. It does not make sense to cache an object indefinitely. Hence, each cacheable entity must also come with a "ttl" that states "how long" an object can be cached. So I also propose we add an additional attribute ttl alongside the allow_caching attribute to the above schemas.

@beckn/core-working-group requesting thoughts on the same.

[pramodkvarma]

Yes agree. Maybe you can simplify by just having TTL. A non positive TTL value (0 or -1) means it is NOT cacheable. That way we don't have to introduce two separate attributes to deal with same.

Also make sure TTL is specified in seconds always without needing any "s" or "m" etc. Let it be always in seconds.