9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Enrico Weigelt <weigelt@metux.de>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] Taking plan9 concepts to *nix
Date: Fri, 29 Jun 2007 13:41:04 +0200	[thread overview]
Message-ID: <20070629114104.GA11889@nibiru.local> (raw)
In-Reply-To: <1183079576.19286.10.camel@linux.site>

* Roman Shaposhnik <rvs@sun.com> wrote:

Hi,

> To me, the biggest advantage of the architecture you seem to have
> in mind is that it becomes extra easy to access and manipulate
> those objects (e.g. bookmarks, visited pages, etc.) from outside
> of the Mozilla.

Yep. That's one side of the story: using some universal storage
and integrating with lots of other applications or sharing between
several instances over the net will be quite trivial.

The oder side is simplicity: Mozilla really suffers from quite
unmaintainable code. Nobody really sees through, and the whole
blob is nearly undebuggable. People invent really sick "solutions"
to non-problems (ie. the mork "database"-format) and avoid really
necessary radical cleanups / refactoring.

My first plan (back several years) was to move out one thing by
another into separate (mozilla independent!) libs. This of course
would work, but compared with the simplicity of an virtual fs
it's just a waste of resources. With an clean and simple model,
the fs can handle 90% of the tasks by itself, and from that point
we can do all these nice things which can be done with an fs
(ie. sharing over the net).

Mozilla folks are working on other solutions which were meant to
go in a similar direction (ie. generalized db api, mork, sqlite)
for quite a long time (AFIAK in FF 3.x, sqlite should be standard),
but they all are additional features, the old crap will still be
carried for a long time. I really wonder, how they can seriously
think about embedded targets in such an sitation ;-O


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------


  reply	other threads:[~2007-06-29 11:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-28 13:29 Enrico Weigelt
2007-06-28 16:59 ` Uriel
2007-06-28 18:32   ` Enrico Weigelt
2007-06-29  1:12     ` Roman Shaposhnik
2007-06-29 11:41       ` Enrico Weigelt [this message]
2007-06-28 21:08 ` Roman Shaposhnick
2007-06-28 21:29   ` Francisco J Ballesteros

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070629114104.GA11889@nibiru.local \
    --to=weigelt@metux.de \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).