Why separate cookies-related classes needed?

[johnd0e]

I have briefly looked through sources, and found that Bard, BardAsync, and ChatBard all have *Cookies counterparts - BardCookies, BardAsyncCookies, ChatBardCookies.

I find that not good at all.

1. It is bad from maintainer's and developer's perspective, as there are some code duplication between them (esp. in BardCookies).
2. And it is not convenient from user's perspective too, as it got a bit complicated (without any gain).

Isn't it possible to refactor code in order to combine cookies- and non-cookies- classes?

[dsdanielpark]

Thank you for your opinion.

I'm fully aware of the issues mentioned:

1. Indeed, modifying parts of the bard object concerning multi-cookies seems prudent.
2. In terms of async, its utility in our current process aligns closely with that of a standard bard object. Essentially, while async implementation isn't necessary now, some contributors have partially refined it after experimenting. Its widespread usage is quite surprising.

Nonetheless, I haven't fully refactored the package because if Google alters the interface, changes cookie values, or intensifies rate limiting, the package would instantly become obsolete.

The longevity and the extent of additional features of the bardapi package were unforeseen. While it started modestly, it now encompasses numerous features, even if some are unnecessary.

In essence, our current situation stems from focusing on rapidly fulfilling feature requests, even if the solutions are temporary.

Moreover, refactoring now, by altering method names or existing functions, would lead to confusion among many users due to the disappearance of classes or modification of methods, escalating into further issues.

Hence, the package remains inefficiently structured.

Ultimately, the reason for not properly optimizing and maintaining the package is its potential obsolescence at any moment, considering it's a free, open-source with likely a short lifespan. I'm reluctant to devote more time to developing this package.

Initially, cookie values lasted between 15 to 30 days. However, they now change in seconds or every 15-20 minutes, with rate limiting also significantly stricter than before.

Nevertheless, if you're inclined to make efficient improvements and submit a pull request, you're always welcome!

[dsdanielpark]

If this year's planned bard advanced doesn't inconvenience users like Gemini in Google AI Studio, and if cookies remain valid at least to their current extent, I do have plans to thoroughly refactor the package with a version update.

However, this is entirely contingent on Google's future actions.

Even after the official API service of bard, if many developers continue using this package and find it valuable, I am considering a complete and clean refactoring with an upgrade in the version for further development.

[dsdanielpark]

Thank you for your review, which has prompted me to revisit an ongoing concern.

Fundamentally, I've realized that fewer users than expected require multiple cookie values for multi-cookie, and async bard doesn't offer significant utility.

Also, the fear that the package could become obsolete at any moment has been looming, especially seeing cookie values that once lasted 15-30 days now change within seconds to 20 minutes. This has hindered me from proceeding with the work.

Despite this, I acknowledge as an open-source package developer, I should have been more careful in adding and optimizing methods and classes. I do regret not taking a bit more time to deploy the initial methods.

However, if Google does not alter the interface and adopts a more lenient approach, I am very much inclined to undertake a thorough refactoring and even release documentation.

I truly appreciate your valuable feedback.

[johnd0e]

Initially, cookie values lasted between 15 to 30 days. However, they now change in seconds or every 15-20 minutes

But for me cookies are far more stable. Just checked with cookies from yesterday - all is ok.
Remember: I use 3 cookies, may be this setup lives longer.

Moreover, refactoring now, by altering method names or existing functions, would lead to confusion among many users due to the disappearance of classes or modification of methods, escalating into further issues.

In fact, it can be done in compatible way: implement all in Bard and make aliases for BardCookies.
And BardAsyncCookies/ChatBardCookies are not even in release yet, so better to not introduce them at all.

the reason for not properly optimizing and maintaining the package is its potential obsolescence at any moment, considering it's a free, open-source with likely a short lifespan.

I believe that Google will not break the functionality of package in near time.
But you have the point.

[dsdanielpark]

johnd0e

Thank you. Following your advice, I will endeavor to maintain the previous method as much as possible, keeping it as legacy, while refactoring the code and preparing new documentation to streamline it.

Currently, I am in the process of integrating the multi-cookie boolean and cookie dictionary into the bard object and reevaluating the entire process.

I hope Google doesn't make the change anytime soon.