Library defaults

Library defaults

[Lars Ingebrigtsen]

Controlling things like cookies and caching is an application-level
thing and not a library level thing (i.e., a browser like eww should
allow the user to control whether to send cookies or not; not a global
setting that affects the lower-level library).

But still, nice defaults in a low-level library is also nice.  This is
the current signature for `with-url':

(with-url (URL &key WAIT TIMEOUT READ-TIMEOUT (VERBOSE 5) (COOKIES t)
(CACHE t) DEBUG HEADERS IGNORE-ERRORS (METHOD "GET") DATA
(DATA-CHARSET 'utf-8) DATA-ENCODING) &body BODY)

The three defaults up for discussion are `verbose', `cookies' and
`cache'.

In application use, most would set verbose to 0 (no messages), but
perhaps it's nice to see a "Connecting to..." message if you're
developing an app `with-url' at first?

Developing with cookies switched on by default...  I don't know.  Most
applications will have that on, but perhaps having a library like that
alter files under ~/.emacs.d/url/cookies should be something that you
opt in to?  Or perhaps it should default to `write', which means that it
sends cookies, but never updates them.

All apps will run with caching switched on (unless the user has
specified something else), but it's the same thing as with cookies: With
a default of t, just fiddling with this function may end up storing
things in ~/.emacs.d/url/cache, which may not be what you want.  So nil
as a default?

So it's really: Make the defaults developer-friendly or source code
friendly?  Because all calls from applications will end up looking like

(with-url ("http..." :cookies t
                     :cache t
                     :verbose 0)
   ...)

And that's kinda sad, too.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Library defaults

[Davis Herring]

> So it's really: Make the defaults developer-friendly or source code
> friendly?  Because all calls from applications will end up looking like
>
> (with-url ("http..." :cookies t
>                      :cache t
>                      :verbose 0)
>    ...)
>
> And that's kinda sad, too.

No, they should end up looking like

(with-url ("http..." :cookies client4--cookies
                      :cache client4--cache)
   ...)

because it is not only the _fact_ of using cookies and cache but also 
the contents of those data stores that should be client-specific. 
Cookies serve as a "persona" that should be under the control of the 
client/user, and the client/user may know when a cache is stale or 
unneeded and want to clear it themselves.  (I imagine there is also a 
privacy concern if two personas are used but they share a cache that can 
be detected via logging the HEAD requests that do not produce a GET.)

In case it's not obvious, client4 would if appropriate offer a 
"don't-use-cookies/cache" customization that caused 
client4--cookies/cache to be nil.

Davis

PS - Yes, non-verbose should be the default, but that is indeed merely a 
stylistic concern.

-- 
This product is sold by volume, not by mass.  If it appears too dense or 
too sparse, it is because mass-energy conversion has occurred during 
shipping.

Re: Library defaults

[Lars Ingebrigtsen]

Davis Herring <herring@lanl.gov> writes:

>> So it's really: Make the defaults developer-friendly or source code
>> friendly?  Because all calls from applications will end up looking like
>>
>> (with-url ("http..." :cookies t
>>                      :cache t
>>                      :verbose 0)
>>    ...)
>>
>> And that's kinda sad, too.
>
> No, they should end up looking like
>
> (with-url ("http..." :cookies client4--cookies
>                      :cache client4--cache)
>   ...)

Yes, major applications would look like that.  (Or really -- eww would
implement a function that would bar "third party cookies" etc according
to user settings.)

But not all clients are larger applications like that, and for those
choosing the wrong defaults would result in slightly sad-looking code.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Library defaults

[Ted Zlatanov]

On Sun, 22 Jan 2017 00:19:23 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Controlling things like cookies and caching is an application-level
LI> thing and not a library level thing (i.e., a browser like eww should
LI> allow the user to control whether to send cookies or not; not a global
LI> setting that affects the lower-level library).

LI> But still, nice defaults in a low-level library is also nice.
...
LI> So it's really: Make the defaults developer-friendly or source code
LI> friendly?  Because all calls from applications will end up looking like

LI> (with-url ("http..." :cookies t
LI>                      :cache t
LI>                      :verbose 0)
LI>    ...)

I think Michael Albinus' work with per-connection profiles/variables is
useful here. I plan to use it with GnuTLS[1], at least, and I think it
could be useful here as well.

Ted

[1] insert pithy footnote about time management