[Dillo-dev]Pending tasks

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi everyone!

  Now  that  0.6.1  has achieved a significant stability gain, we
can  focus  on  several  other  tasks  that  were  waiting in the
priorities queue.

  Note  that  the  stabilization  is  not completed, but advanced
enough to let other tasks to be started.

-----------------
Attribute parsing
-----------------

  As  I  posted  before (Subject: "Attribute parsing"), this is a
high  priority  task that's pending. I received emails from Bruno
and  J=F6rgen stating that they were willing to work on it, but not
knowing  exactly  were to start. My current schedule contemplates
working  on this, the networking part of plugins, https and auth.
So  If  I start with the latter I'll have little time to help you
both,  so  J=F6rgen:  if  you  feel  confident  enough  to  work on
attribute  parsing, starting from my previous post, please let me
know  so I can focus on networking; if not, let me know also so I
can start here.

  Note that there're other interesting tasks in this post that if
you feel more comfortable with, can be as helpful to work on.

--------------------------------------
Bug 216 (answers without content/type)
--------------------------------------

  Yes, I also had this problem with ebay (made a little hack, and
won  my  bid!).  Since that moment the idea of handling this case
the  rigth  way  is  present. Note that the problem arises from a
http answer lacking the content/type info; the RFC says it SHOULD
be present, so it's not an error :(

  The  solution  is simple, do you remember magic numbers and the
'file'  command? Well, that's the way to go. I don't mean calling
'file'  and  parsing its output, but to examine the magic numbers
file  (and  its  format)  for  the  small set of MIME types dillo
supports:

  image/{png, jpeg, gif}
  text/{plain, html}

  and  afterward,  to  create  a custom function that returns the
MIME  type  of a file, by examining a few bytes from the start of
it. Ex:

  gchar *a_Mime_get_content_type(const gchar *FewBytesString);

  After having this function, it's just a matter of binding it to
header parsing.

--------------------
Dicache memory usage
--------------------

  The  cache  system (cache and dicache) uses a lot of memory for
images,  because  it  stores  the  original  format  and  the RGB
decompressed one.

  Flushing  the dicache is not easy because image widgets use the
dicache  buffers  directly.  The  right  solution is to implement
a memory usage threshold on the dicache, but that would require a
significative effort...

  As   a   workaround,   there's  a  posibility  of  binding  the
'about:splash'  method  (because  it  doesn't  use  images)  to a
dicache  flushing  function.  i.e.  whenever the splash screen is
requested,  the  handling  method  asserts  there's only a single
browser window open and flushes the dicache (after displaying the
splash).

  This  is very far from a clean solution, but may serve those of
you that feel in a dire need of it.

-------
Plugins
-------

  One of the most procrastinated topics in dillo :(
  After  attribute  parsing  is  done,  I'll  be choosing between
plugins and the networking part of https, cookies and auth.

------------------------
https, cookies and auth.
------------------------

  There were three issues to this:

    1) Stability   (almost achieved)
    2) The specific implementation layer and network support
       for them.
    3) https pages usually require working cookies.

  As  Tor-Ake and J=F6rgen have advanced with 2 and 3, I'll need to
know  what  this  schemes require from the networking layers (for
instance, cookies require sending back stored cookies).

  If  you  guys  work together, and specify what you require from
the  networking  layers,  and  keep  on  improving  the  specific
implementation,  it  will  come  a  time  when  I'll  be  free to
implement  the  underlaying  support  and  hopefully  then, it'll
become a matter of merging.

  Note that cookies should provide dillorc options for:

  - rejecting all cookies
  - accepting only if the RootUrl and server match.
  - accepting all
  - [confirm]   -- this must be very well thought, for not
                   annoying the user.

-----------------
Frames workaround
-----------------

  Before  the  final  implementation  of frames, a workaround (as
dicussed  on  the list) would be a nice addition. I'll be waiting
until Livio finishes testing and polishing the current prototype.

-------
History
-------

  We are working with Eric on it. Expect a full creative solution
to be there sometime :)  I'm crossing fingers.

-----------------------
BUG 205 (visited links)
-----------------------

  This is not a bug, but a feature!
  In dillo, visited link sematic is "cached".
  (it has proven useful)

  Note: 205 will be removed soon from BugTrack.

----------------
nowrap and width
----------------

  The  workaround  for  this construct was removed in concordance
with dillo's html parsing policy ([Project Notes]).

  Also note that the HTML 4.01 spec says WIDTH is a "recommended"
cell   width   (hints  in  dillo's  implementation),  and  NOWRAP
"disables  automatic  text  wrapping  for this cell", and it adds
"NOTE:   if   used  carelessly,  this  attribute  may  result  in
excessively wide cells".

  So current implementation is compliant with both.

  Regards
  Jorge.-