Re: "mailto:" + EXTERN wishlist [lynx-dev]

[Klaus Weide]

On Mon, 7 Jun 1999, Vlad Harchev wrote:
> On Sat, 12 Jun 1999, Klaus Weide wrote:
> > On Mon, 7 Jun 1999, Vlad Harchev wrote:
> > > 
> > > ... Another kind of such trick - add required
> > > info at the end of the url string (ie after 0 character - so url will be
> > > pretty clean for string functions, but special information will be placed
> > > after that 0 and between next 0). ...
> 
>  I was serious. And I don't think it's so crazy idea.

It very likely would make the code much harder to understand for others.

Up to now, a string can be shortened by just overwriting one of its chars
with '\0', and I think various pieces of code do that.  You'd have to
check for all places where that can potentially occur, and shift the hidden
extra info around when it happens to that kind of URL.  And make sure that
all future developers are aware of this pitfall (effectively impossible).

> > > > Moreover this would only work for mailto: URLs, not for other cases 
> > > > where
> > > > TITLE also may be useful.
> > >  
> > >   Another approach I proposed in this letter can solve the problem. But I
> > > can't imagine where else title information can be useful.
> > 
> > Title information can be useful if people put useful information into
> > TITLE attributes.
> 
>   But I still don't see any use of it _AFTER_ text is rendered. Of course
> while rendering text we can somehow insert TITLE information in the rendered
> version, but after it was rendered, seems it's only useful for mailto: links.
> Please correct me if I'm wrong.

I am suspicious of "I don't see any use of it" as an argument.  Lots
of things could be done if the TITLE were available to an external
program.  For example, write your own bookmark-adding or -checking
implementation (lynx_bookmarks compatible or not; maybe compatible with
some other software's format).  Maybe that's useful for someone and maybe
not, but making TITLE available only for the special case you can think
of seems like an artifical restriction.

>    RAM is our friend too.

The advantages of saving memory should be weighed against the
advantages of generality and simpler code.  There are already
mechanisms to reduce memory (conditional compilation; reduce
some parameters in userdefs.h like MAXHIST and MAXLINKS; enforce
restrictions with ulimit/limit).  I don't want to make excuses
for wasting memory, but squeezing the last bit of savings out
of some code can make it un-reusable, so the next person that
comes along with a slightly different requirement will reinvent
the wheel and the end result may be more not less resource
consumption.  (Not that I always practice what I preach...)

   Klaus