search

kjetilk / p5-lwp-useragent-chicaching

LWP::UserAgent with caching based on CHI
0 stars 2 forks source link

Document competitive alternatives #5

Open jonassmedegaard opened 6 years ago

jonassmedegaard commented 6 years ago

Hi,

Would be nice if POD for LWP::UserAgent::CHICaching had a section SEE ALSO, either a simple list, or preferrably more details on how - in the opinion of the author - each compare to LWP::UserAgent::CHICaching.

These seem relevant to consider as competitors:

Some related but somewhat dated info found at http://neilb.org/reviews/http-requesters.html

kjetilk commented 6 years ago

Thanks! It is good to have a compiled list :-) I don't know if I will get time to review all these though, but it is an interesting exercise to do at some point.

jonassmedegaard commented 6 years ago

Quoting Kjetil Kjernsmo (2017-09-29 12:07:48)

Thanks! It is good to have a compiled list :-) I don't know if I will get time to review all these though, but it is an interesting exercise to do at some point.

Perhaps as a starting point - to make it possible for others (me?) to help - you could elaborate here in the issue on the kind of features you felt lacking when you started out, and when you started out.

You briefly(!) mention that it is about HTTP 1.1 tags like Etag. If you elaborate on which details in HTTP 1.1 are important for your use cases, others might help by listing potential competitors seemingly covering same features.

When did you decide to create this? That detail could help others helping you, by listing the competitors seemingly introduced or enhanced since you started.

--

kjetilk commented 6 years ago

I commented very briefly on it in the POD:

But why? Mainly because I wanted to use CHI facilities, and partly because I wanted to focus on HTTP > 1.1 features.

But it is also the thing that some not very nice things are often best unsaid... :-) It was really hard in the code I looked at to see if they were actually spec compliant. So, to say that in a nice way that is constructive is actually fairly hard, and to do that in my own module would just be a snapshot anyway. Moreover, I think that the whole LWP stack should be rewritten with roles, so this is kind of a start, but I wouldn't have any more time to commit to that anyway, so I don't feel like just complaining about it.

The initial release was 2015-02-17, that gives a timeframe.

jonassmedegaard commented 6 years ago

Quoting Kjetil Kjernsmo (2017-09-29 13:15:16)

I commented very briefly on it in the POD:

But why? Mainly because I wanted to use CHI facilities, and partly because I wanted to focus on HTTP > 1.1 features.

But it is also the thing that some not very nice things are often best unsaid... :-) It was really hard in the code I looked at to see if they were actually spec compliant. So, to say that in a nice way that is constructive is actually fairly hard, and to do that in my own module would just be a snapshot anyway. Moreover, I think that the whole LWP stack should be rewritten with roles, so this is kind of a start, but I wouldn't have any more time to commit to that anyway, so I don't feel like just complaining about it.

Makes sense. But then again, when left unsaid you make it impossible for others to help out.

Perhaps something like "This implementation currently is believed to handle features $Foo and $Bar spec-compliant (as of february 2015)" - that would hint at you expecting at that point in time that other implementations doesn't do those same features (at all or correct).

Additionally mentioning "See also: LWP::Baz, LWP::Boink::Fatty" would hint at which modules you are aware of and consider not addressing the above documented features - again without pointing fingers at them (on the contrary a "See also:" notice without further comments can be seen as an "if this module doesn't suit your fancy, I recommend that you take a look at these other fine implementations".

The initial release was 2015-02-17, that gives a timeframe.

Thanks!

--