mr. fromme almost gets to the point that i am about to make.

every so often, some one posts a complaint about another entity's browser.
it can't do this, it can't do that, "blah, blah, woof, woof"
  [ the quote is from jimi hendrix; monterey, 1967, iirc ].

question:  if the "browser_products" of other entities are --so-- problematic,
             just --how-- difficult would it be to "roll our own" ?

note that this question is --not-- the same as asking
  how long it would take to code all of the whiz_bangs
  that the marketing_department_dweebs want to advertise.

it doesn't have to do everything,
  but, what it does do must be done well; reliably, predictably.

i would want it to do things "the bsd way", e. g., search by reg_ex.
it would be totally divorced from anything "gnu".
i don't care about animation [ images hog bandwidth, big_time ].

here is a concept about which i have fantasized for quite some time.
i have been writing a book_keeping app that is
  designed to do certain things that i have not found to exist in
  any of the pre_fab, out_of_the_box, point_and_click thingies,
  which are available for purchase
  [ "ask about our multi_user_license program" ]
  at the big_box store.
for quite some time, off_and_on, admittedly,
  i have been researching how to write a "browser".
it is my understanding that,
  once i can recursively render tables, the rest is comparitively easy.
i have not, just yet, figured_out how to do the secure_http thing
  [ this is where i am stalled ].
i want a program
  that, either, is or, to the outside_world, appears to be a "browser"_like 
thingy and
  which is --programmable--,
  so that it may, in co_ordination with my book_keeping app,
  log in to any account,
  >----> to which i am already authorized access, <----<
  such as my bank or my electric_utility,
  in the middle_of_the_night, while i am asleep,
  to down_load transaction_events or other postings,
  to up_load bill_payment schedulings or other instructions,
  so that i don't have to use my waking moments to
  do these routine, but, necessary, time_consuming chores.
this is an example of the bsd approach, "routine tasks should be scripted".
further, i want this "browser" to be a "logging" "browser",
  making a disk_copy of --every-- page that comes in,
  text, image, --everything--,
  so that i do not have to remember to "save" a copy of the page,
  even from so_called "secure" sites
  [ i have confidence in my ability to
      secure sensitive information and to manage log_files
  ].

to get to the topic of "bounties",
  it is with deep regret that i inform all readers that,
  "for the duration" of the global_economic_depression,
  presently being engineered by the american donkey political_party,
  with the able assistance of their front_man, the "magic_messiah"
  [ for whose failure, i pray several times per day ],
  i will be unable to supply any funds to the "bounty" program
  [ surely, there is a better word, isn't there ? ].
however, especially after the book_keeping app is working,
  i anticipate having more time available.
as my bsd skills continually improve,
  my confidence in, one day,
  being able to make a credible contribution to the freebsd project
  improves commensurately.

[ an aside to mr. stokely.

  regarding a dialogue in which you took part about a month ago,
    i am pleased to learn that your need is for author people, not mark_up 
people.
  i frequently find myself making copies of files,
    e. g., "man" pages or "info" docs,
    then, amending them to
    add examples or explanations,
    fix spelling, grammar and punctuation
    [ the comma is great for setting_off subordinate clauses ] errors,
    rewrite tortured phrasing and,
    sometimes, correct content errors.

  "fixing things" may be where i may be of initial service.

  as an example [ this one is current ],
    have any of you ever tried to teach yourself m4(1),
    with only the "man" page available ?

  i wanted a general_purpose macro_instruction processor.
  on faith, i assumed that "m4" wouldn't be included, if it wasn't useful.
  further, i assumed that it was a "current" tool, because,
    if "m4" was a "legacy" tool, another tool, "for new designs", would exist.
  i had never before been able to make "m4" work "right",
    but, this time, considering the above reasoning,
    i decided to stick with it for more than a few hours
    [ now, i know why:  i am line_oriented ].
  having some initial success, i kept at it, grumbling frequently
    [ if it hadn't been for the "-dV" option,
        i would, probably, have given_up --very-- early on;
        the quoting approach is --not-- intuitively obvious
    ].

  i went three full weeks before i discovered that
    the "info" doc is in "/usr/local", not "/usr/share",
    where i had found the "cc" and "as" "info" docs.
  "make" was with it [ surprise ! ].
  shouldn't those all be in one place ?
  to make things worse,
    the "man" page and the "info" doc assume --opposite-- defaults.
  further, the "info" doc describes feat^H^H^H^Hcharacteristics
    which, in fact, do not exist
    [ perhaps, stallman recruited that author from a redmond marketing firm ].
  after several more weeks of hacking,
    i have, for the most part, figured_out what does work and what does not 
work.
  i have even developed techniques to
    insert nearly arbitrary white_space into my macroes,
    rendering them amazingly readable.
  this past monday, i installed sendmail [ the latest one; 8_14_3, i think ],
    so that i can see examples of actual use.
  i haven't needed to translate between looping and tail_recursion
    since my fortran days.

  i realize that this is a "gnu" product, so, i put the blame there.
  however, it illustrates my point.

  but, i digress.
]

sorry to go on at such length.
perhaps, if i were to post more frequently, my posts would be shorter.
when i started this, i thought i would type only about one paragraph,
  asking the "roll our own" question.

for ready reference, i enclose the relevant portions of mr. fromme's post.

rob spellberg



Oliver Fromme wrote:
Matt Olander wrote:
 > james michael wrote:

[ snip ]

> > ... but I don't > > think the problem is that people aren't willing to do the work, its > > that places like adobe has closed its software so that we can't > > really create anything. > > Actually, Flash9 on FreeBSD 7.x is working pretty good now with Linux > emulation.

Unfortunately only with Firefox, and it's far from perfect.

I tried to get Flash9 working the past few days with the
latest RELENG_7 and the latest ports.  This is on a UP
i386 machine, so nothing special.

 - Native Opera:  No go.  It segfaults.

 - Linux Opera:  Works somewhat, but hangs often, leaves
   lots of dead processes behind.  Generally unusable.

 - Native Firefox3:  Works most of the time.  Problems
   with youtube (hangs quite often).  Most other sites
   seem to work better.

 - Linux Firefox:  Didn't try because the port is marked
   "forbidden" due to security issues.

I definitely prefer Opera for normal browsing because it's
faster and has more useful features, so I use it most of
the time.  I only start up Firefox when I need to visit
a site that requires Flash, which doesn't happen too
often, fortunately.

Certainly, I wouldn't mind if someone improved the existing
nspluginwrapper to work better with native Opera, or write
a new software from scratch that enables using Flash with
native Opera.

[ snip ]

Best regards
   Oliver

_______________________________________________
freebsd-chat@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-chat
To unsubscribe, send any mail to "freebsd-chat-unsubscr...@freebsd.org"

Reply via email to