> This is the approach that the recent TSHttpTxnCacheLookupUrlGet API took. We > should take a consistent approach across the API. Its confusing and harder > than necessary when some APIs take strings and some take TS objects.
As I wrote on the second to last mail, I guess the URLs would come from out of TS APIs. So if we require TSMLoc, it means plugin developers need to create a TSMBuffer somehow and pass a offset to a URL, to just pass a URL. Is this really convenient to plugin developers? > Why did you want to overload it? I tried to provide two APIs, URL object version and string version. One is for a case that a URL comes from other TS APIs, and another one is for a case that a URL comes from out of TS APIs. On Thu, Aug 18, 2016 at 5:20 AM, James Peach <jpe...@apache.org> wrote: > >> On Aug 17, 2016, at 9:36 AM, Masakazu Kitajo <mas...@apache.org> wrote: >> >> I realized that URL class isn't exposed as a part of TS API. None of >> APIs receive it explicitly, and TSMLoc is used instead. > > This is the approach that the recent TSHttpTxnCacheLookupUrlGet API took. We > should take a consistent approach across the API. Its confusing and harder > than necessary when some APIs take strings and some take TS objects. > >> Also, I >> couldn't overload the API because it's not C++ but C. > > Why did you want to overload it? > >> >> So, I think passing URLs as strings is a reasonable way, and it is the >> only option for now. >> >> I'm going to start writing documentation this weekend and merge the >> Pull Request by next weekend. Please comment if you have any thoughts. >> This would be the final call since there's no responses in last 10 >> days. >> >> Thanks >> >> >> >> On Sat, Aug 6, 2016 at 6:13 PM, Masakazu Kitajo <mas...@apache.org> wrote: >>> What do you think about providing the both interfaces? >>> >>> I'm fine with passing URL objects internally. However, I guess there >>> are cases that URL strings comes from out of TS APIs such as >>> databases, results of some processing, etc. Though people can create >>> URL objects easily, it needs few more boring codes in every plugins. >>> >>> >>> On Sat, Aug 6, 2016 at 12:08 AM, Leif Hedstrom <zw...@apache.org> wrote: >>>> >>>>> On Aug 4, 2016, at 8:15 PM, James Peach <jpe...@apache.org> wrote: >>>>> >>>>> >>>>>> On Aug 1, 2016, at 12:18 AM, Masakazu Kitajo <mas...@apache.org> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I'd like to add a new API to support Server Push[1] introduced by HTTP/2. >>>>>> >>>>>> void TSHttpTxnServerPush(TSHttpTxn txnp, const char *url, int url_len) >>>>> >>>>> I think the direction we are moving in is to pass URLs as URL objects >>>>> rather than strings. >>>> >>>> >>>> Definitely. >>>> >>>> — leif >>>> >>>>> >>>>>> >>>>>> This allows plugins to push contents with Server Push mechanism >>>>>> supported by client session protocols. Currently, the API can be used >>>>>> with HTTP/2 sessions but it will be used with QUIC[2] sessions too in >>>>>> the future. >>>>>> >>>>>> I think the API should be marked as experimental, and it need to be >>>>>> brushed up with practical use cases. However, at least, it should >>>>>> satisfy the simple approaches discussed on TS-3474. >>>>>> >>>>>> JIRA: >>>>>> https://issues.apache.org/jira/browse/TS-3474 >>>>>> >>>>>> Pull Request: >>>>>> https://github.com/apache/trafficserver/pull/833 >>>>>> >>>>>> [1] https://tools.ietf.org/html/rfc7540#section-8.2 >>>>>> [2] >>>>>> https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00#section-9 >>>>>> >>>>>> Thanks, >>>>>> Masakazu >>>>> >>>> >
