lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vlad Harchev
Subject: Re: "mailto:" + EXTERN wishlist [lynx-dev]
Date: Mon, 7 Jun 1999 14:32:34 +0500 (SAMST)

On Mon, 14 Jun 1999, Klaus Weide wrote:

> 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).

 I'm not sure, but seems that links[] are read-only - ie no modifications are
 done to them after that array was filled. I agree that it will make code
 harder to understand for others.

> > > > > 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

 Please don't consider this as an argument. This was my belief.

> 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.

 OK, approach proposed by me can be used not only for mailto: urls.
 
> >    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...)

 Adding another member of structure (pointer to chars) (and allocating chunk
of memory to put TITLE's value in it) will make memory more fragmented than 
allocating url and title in one chunk.
 But the biggest disadvantage of my apporach is the fact that it's unusual and
uncommon.

 But this was my POV, and I don't think approach I proposed is by far better
than adding additional structure member. Klaus, feel free to implement (or
not implement at all) storing value of TITLE in any way you like.

>    Klaus
> 

 Best regards,
  -Vlad


reply via email to

[Prev in Thread] Current Thread [Next in Thread]