removing core RDF support in Moz2?
Myk Melez
mimeTypes.rdf (the three remaining RDF datastores in Firefox 3, as far
as I can tell) to mozStorage for the Firefox release after Firefox 3
(the one off a 1.9 branch in cbeard's proposed revision to the Firefox
release roadmap <http://people.mozilla.com/~cbeard/roadmap/>)?
Could we then remove our core RDF support in Moz2, because enough users
would have moved over to Firefox 3+1 that it would be ok for Firefox 3+2
not to migrate those files for the few users who migrate directly from
Firefox 3 to Firefox 3+2?
Then we'd free up others to provide better RDF implementations installed
as plugins/addons for use cases that really need RDF while slimming down
our codebase.
-myk
Axel Hecht
in the scope of the 1.9.1 discussion, but if we had a 1.9.1 (or whatever
we call it) it'd sure be an interesting migration strategy.
If RDF/XML profile migration is big enough of a deal to make an argument
in favour of 1.9.1 is something I'd leave up to brendan.
I'm mostly concerned about localstore. That thing is as one heavily
intertwined into XUL, and it's also used by extensions out there as a
data dumping ground, if they didn't bother creating their own
datasource. Ripping out xul persistance based on localstore.rdf and
backing it up by another storage is something that I'd consider bad
enough to rev the gecko version. That doesn't say a whole lot about
other gecko changes going in.
Axel
Robert Sayre
>
> Ripping out xul persistance based on localstore.rdf
I don't think anyone is proposing "ripping out" RDF. Let's remove it in
a manner that's prudent and well-tested. :)
- Rob
bre...@mozilla.org
> Here's a thought: what if we moved extensions.rdf, localstore.rdf, and
> mimeTypes.rdf (the three remaining RDF datastores in Firefox 3, as far
> as I can tell) to mozStorage for the Firefox release after Firefox 3
> (the one off a 1.9 branch in cbeard's proposed revision to the Firefox
> release roadmap <http://people.mozilla.com/~cbeard/roadmap/>)?
I'm on the record as thinking that plan is not the one we want, if we
can prove Mozilla 2 ready this year, take on most 1.9 developers
around end of year, and get Mozilla 2 (= 1.9.1/fx3.5 + Tamarin +
deCOMtamination and C++ frozen API -- no new frozen APIs) done and
ready to ship in 2008. But this is grist for another post, and for
m.d.planning.
> Could we then remove our core RDF support in Moz2, because enough users
> would have moved over to Firefox 3+1 that it would be ok for Firefox 3+2
> not to migrate those files for the few users who migrate directly from
> Firefox 3 to Firefox 3+2?
We could migrate no matter the 1.9.1 vs. 2 issue. At the minimum, we
would just need the backward compatible RDF/XML parser in order to
migrate .rdf files forward.
/be
Myk Melez
> I didn't dare to raise my hand about profile migration and RDF/XML data
> in the scope of the 1.9.1 discussion, but if we had a 1.9.1 (or whatever
> we call it) it'd sure be an interesting migration strategy.
I wouldn't say this is an argument in favor of 1.9.1. Rather, it's the
opposite: I'm saying we shouldn't touch RDF for Firefox 3+1, i.e. no
changes to RDF on the 1.9 branch from which Firefox 3+1 is built (if so
built, but see brendan's post arguing for Firefox 3+1 off Moz2).
But on the front-end we should remove all core uses of RDF from Firefox
3+1, so it only uses RDF support to migrate legacy RDF datastores (of
which I'm only aware of the three I mentioned earlier) to new
mozStorage-based datastores.
And we should evangelize extensions that RDF support is going away in
Moz2, to give them time to migrate to mozStorage (although RDF would
continue to work in 3+1, so they wouldn't have to migrate immediately).
-myk
Robert Strong
elsewhere will require the change to be made in a non API compatible
release.
Robert
Matthew Gertner
What would you do about install.rdf?
Matt
Robert Strong
> What would you do about install.rdf?
install.rdf's
Robert
Myk Melez
> What would you do about install.rdf?
I would define a new non-RDF install manifest format, support both for
the Firefox 3+1 release (encouraging extension authors to switch to the
new format), and then support only the new format for the Firefox+2 release.
-myk
Justin Dolske
>> What would you do about install.rdf?
>
> I would define a new non-RDF install manifest format
install.xml!
mark....@gmail.com
> What would you do about install.rdf?
>
> Matt
Isn't our 'install.rdf' just ugly looking XML? Do we really need an
RDF parser to handle it?
Robert Strong
use make using an rdf parser desireable. I'd also like to move to a
different format at some point since it can be a pain for new extension
authors to work with.
Robert
Matthew Gertner
Here, here. Unless there's a reason to use RDF (anyone?) I'd be keen to
see a simplified XML format. Mark's right that the serialization is XML
anyway so in reality changes could be minimal (e.g. put everything in
the same namespace, get rid of the strange RDF and Description tags, etc.).
Neil
> Could we then remove our core RDF support in Moz2
Do we have documentation for replacements of all of the uses of RDF (and
I mean replacements rather than workarounds)?
--
Warning: May contain traces of nuts.
Matthew Gertner
> Myk Melez wrote:
>
>> Could we then remove our core RDF support in Moz2
>
> Do we have documentation for replacements of all of the uses of RDF (and
> I mean replacements rather than workarounds)?
Someone should create a wiki page for this.
Michael Vincent van Rantwijk, MultiZilla
> Neil wrote:
>> Myk Melez wrote:
>>
>>> Could we then remove our core RDF support in Moz2
>>
>> Do we have documentation for replacements of all of the uses of RDF
>> (and I mean replacements rather than workarounds)?
I agree with Neil here, don't remove anything until people are satisfied
with the documentation, which is still rather flaky at best.
> Someone should create a wiki page for this.
Make that someone with complete understanding of the code involved, and
he/she (Deb?) should not walk away until this thing is a deep frozen
tomato :-)
--
Michael Vincent van Rantwijk
- MultiZilla Project Team Lead
- XUL Boot Camp Staff member (ActiveState Training Partner)
- iPhone Application Developer
Benjamin Smedberg
I don't see any need to stop supporting the existing format: writing a
simple RDF parser as a JS module is a 500-line exercise (see bug 357276).
If we want to define a new, simpler XML format, that's fine, but let's avoid
unnecessary churn.
--BDS
Benjamin Smedberg
> I'm mostly concerned about localstore. That thing is as one heavily
> intertwined into XUL, and it's also used by extensions out there as a
> data dumping ground, if they didn't bother creating their own
> datasource. Ripping out xul persistance based on localstore.rdf and
> backing it up by another storage is something that I'd consider bad
> enough to rev the gecko version. That doesn't say a whole lot about
> other gecko changes going in.
We need some data on this. If people are just using localstore for
xul:persist (markup and scripted), that is easy to port to a sqlite
database. If extensions are using the localstore as an RDF datastore, and
especially with XUL templates, they will have orphaned data they will need
to import. Of course with the RDF compatibility parser this will be
possible, but harder.
--BDS
Robert Strong
to chrome.manifest where we still have backwards compatibility with
contents.rdf by converting it to a chrome.manifest. To do this we would
need a simple RDF parser.
Robert
Myk Melez
> Myk Melez wrote:
>
>> Could we then remove our core RDF support in Moz2
>
> Do we have documentation for replacements of all of the uses of RDF (and
> I mean replacements rather than workarounds)?
I know of two uses of RDF in our codebase: storage and dynamic user
interface generation via templates. The replacement for RDF-as-storage
is mozStorage, for which documentation is available here:
http://developer.mozilla.org/en/docs/Storage
The replacement for RDF-for-UI-generation is XML-based templates, for
which incomplete documentation is referenced on the "Firefox 3 for
developers" page:
http://developer.mozilla.org/en/docs/Firefox_3_for_developers#Template_Changes
-myk
Neil
> The replacement for RDF-for-UI-generation is XML-based templates, for
> which incomplete documentation is referenced on the "Firefox 3 for
> developers" page:
>
> http://developer.mozilla.org/en/docs/Firefox_3_for_developers#Template_Changes
Unfortunately there's no replacement query processor mentioned there :-(
I guess either XML or storage would suffice, assuming that it would be
possible to access both memory and file-based datasources.
Dave Townsend
So I've actually happened to look into this a little today (see my other
post for why) and we actually have a number of places in tree that use
as a plain rdf datasource. For instance it looks like seamonkey create
an rdf container to hold the history of their url bar. Places even uses
it to persist the open states of containers.
Removing the rdf-ness from persisting xul attributes is actually going
to be pretty simple compared to the rest.
Dave
Neil Deakin
> The replacement for RDF-for-UI-generation is XML-based templates
No, it is not. Such a replacement for RDF in the UI does not exist, not
has anyone ever proposed anything that would accomplish this.
Neil
Benjamin Smedberg
> The replacement for RDF-for-UI-generation is XML-based templates, for
> which incomplete documentation is referenced on the "Firefox 3 for
> developers" page:
As Neil Deakin says, this is incorrect. If anything, the current replacement
for RDF-in-templates is a custom nsIXULTemplateQueryProcessor implementation
(which is hard!), or better, somebody can work on a JSObject template engine
that could generate UI from a JSON-like JS object structure.
--BDS
Matthew Gertner
We've done some fairly extensive research into existing template engines
that might be candidates for a standard Mozilla engine. We looked
primarily at Python and C++-based solutions. The former are quite cool
but would require linking to the Python runtime (probably a
non-starter). Of the C++ solutions, I believe that CTemplate looked most
promising. That said, the idea of a JS-based engine along the lines of
existing Python systems (could we take an existing engine and replace
Python with JS?) sounds very promising. Mozilla should have a proper
built-in template engine for generating markup.
You can read about our survey here:
https://krtek.allpeers.com/dokuwiki/doc:func:ui_templates
Axel Hecht
Not that the code in that attachement actually does that. It's a parser
for RDF/XML as the W3C has it, not as we implement it currently. The XML
format we serialize and parse is based on an old version of that, at
best. It's undefined and doesn't have any testcases that would allow us
to check for dataloss by using a different parser.
Axel
Axel Hecht
That is on a broken cert and requires log-in.
Axel
Neil
> I've actually happened to look into this a little today (see my other
> post for why) and we actually have a number of places in tree that use
> as a plain rdf datasource. For instance it looks like seamonkey create
> an rdf container to hold the history of their url bar.
That's stored in localstore for some reason, but I'm sure it could
easily be converted so some other data store; we're not proposing to
migrate it from previous versions.
> Places even uses it to persist the open states of containers.
All chrome rdf-based trees do that anyway, and that's localstore again,
so...
Neil
> Dave Townsend wrote:
>
>> I've actually happened to look into this a little today (see my other
>> post for why) and we actually have a number of places in tree that
>> use as a plain rdf datasource. For instance it looks like seamonkey
>> create an rdf container to hold the history of their url bar.
>
> That's stored in localstore for some reason, but I'm sure it could
> easily be converted so some other data store
Hmm, there seem to be a lack of appropriate data stores. Features required:
1. Ability to maintain ordering
2. Ability to remove items
3. Ability to append items
4. Shared across windows
RDF: 1, 2, 3, 4 :-)
XML: 1, 2, 3; 4 could be implemented by reading and writing the XML each
time, or by using a component to cache the instance
prefs: 1, 3, 4; 2 could be implemented with difficulty
sqlite: 2, 3; don't know about 1 or 4
Any other ideas?
Benjamin Smedberg
> Not that the code in that attachement actually does that. It's a parser
> for RDF/XML as the W3C has it, not as we implement it currently. The XML
> format we serialize and parse is based on an old version of that, at
> best. It's undefined and doesn't have any testcases that would allow us
> to check for dataloss by using a different parser.
One of the older versions (which may not be in that bug) parsed localStore
just fine. The version in the bug parses all install.rdf that I could find.
Making the parser accept our current semi-broken RDF isn't hard: you have to
relax some of the rules about unprefixed attributes. I specifically punted
on support for the special literal types (integer literal).
Having testcases would be nice, sure ;-)
--BDS
Myk Melez
> Hmm, there seem to be a lack of appropriate data stores. Features required:
>
> 1. Ability to maintain ordering
> 2. Ability to remove items
> 3. Ability to append items
> 4. Shared across windows
>
> RDF: 1, 2, 3, 4 :-)
> XML: 1, 2, 3; 4 could be implemented by reading and writing the XML each
> time, or by using a component to cache the instance
> prefs: 1, 3, 4; 2 could be implemented with difficulty
> sqlite: 2, 3; don't know about 1 or 4
SQLite doesn't order records explicitly, but ordering is simple to
implement. One just needs to maintain a sort key for records with the
proper ordering.
As for 4, it's the same as for XML: you can write a component that
caches the instance (this is what Places and Site Specific Preferences do).
-myk
Myk Melez
What does the XML template query processor lack that we need for the
templates that currently use the RDF template query processor?
-myk
Neil Deakin
The XML template processor requires the use of XML. None of the existing
datasources use XML and most cannot be converted to do so.
/ Neil
Myk Melez
There's also the mozStorage template query processor being worked on
over in bug 321172
<https://bugzilla.mozilla.org/show_bug.cgi?id=321172>, which could
perhaps be used in conjunction with an in-memory mozStorage database to
replace RDF-based templates used with in-memory datasources.
-myk
Neil
> SQLite doesn't order records explicitly, but ordering is simple to
> implement. One just needs to maintain a sort key for records with the
> proper ordering.
Maintain... something I don't have to do with RDF or XML, because they
already do what I want :-)
One idea I did have was to use an autoincrement field, which would then
give me an ordering of the records, and deleting and reinserting records
to reorder them would not be a problem, but I can't see how to delete
all but the first MAX_URLBAR_HISTORY_ITEMS entries though.
> As for 4, it's the same as for XML: you can write a component that
> caches the instance (this is what Places and Site Specific Preferences
> do).
In that case, I'm tempted to use XML for this, since I can then create
the nodes in the XUL namespace and import them :-)
Justin Wood (Callek)
I'm not sure sqlite's feature set, but ORDER BY, LIMIT, are sql commands
that could prove useful in both cases.
Do we want to DROP items from the urlbar history, or would we rather use
a real history store and query the urlbar history from that?
~Justin Wood (Callek)
Myk Melez
> One idea I did have was to use an autoincrement field, which would then
> give me an ordering of the records, and deleting and reinserting records
> to reorder them would not be a problem, but I can't see how to delete
> all but the first MAX_URLBAR_HISTORY_ITEMS entries though.
On other SQL database systems you'd be able to do:
DELETE FROM <table> ORDER BY <autoincrement field> LIMIT
<MAX_URLBAR_HISTORY_ITEMS>;
That syntax isn't supported on SQLite, but subselects are, so you can
instead do:
DELETE FROM <table> WHERE <autoincrement field> IN (SELECT
<autoincrement field> FROM <table> ORDER BY <autoincrement field> LIMIT
<MAX_URLBAR_HISTORY_ITEMS>);
Note that SQLite maintains an autoincrement field for every table
<http://www.sqlite.org/autoinc.html>, whether you declare one or not, so
you can use it for ordering without explicitly defining one.
-myk
Neil
> Do we want to DROP items from the urlbar history, or would we rather
> use a real history store and query the urlbar history from that?
URLbar history is completely different, silly.
Neil
> DELETE FROM <table> WHERE <autoincrement field> IN (SELECT
> <autoincrement field> FROM <table> ORDER BY <autoincrement field>
> LIMIT <MAX_URLBAR_HISTORY_ITEMS>);
That's not right, that will delete those items, not keep them... I think
I want DESC LIMIT 1 OFFSET <MAX_URLBAR_HISTORY_ITEMS>;
> Note that SQLite maintains an autoincrement field for every table
> <http://www.sqlite.org/autoinc.html>, whether you declare one or not,
> so you can use it for ordering without explicitly defining one.
It's a shame that unless you go for the slower INTEGER PRIMARY KEY
AUTOINCREMENT you can't delete the newest inserted row though... how do
you tell that the row you want to delete is the newest?
Myk Melez
> Myk Melez wrote:
>
>> DELETE FROM <table> WHERE <autoincrement field> IN (SELECT
>> <autoincrement field> FROM <table> ORDER BY <autoincrement field>
>> LIMIT <MAX_URLBAR_HISTORY_ITEMS>);
>
> That's not right, that will delete those items, not keep them...
Err, sorry, right. To keep those items, change the operator in the
outer WHERE clause to NOT IN.
> I think I want DESC LIMIT 1 OFFSET <MAX_URLBAR_HISTORY_ITEMS>;
This will only delete one record, which doesn't sound like what you want.
> It's a shame that unless you go for the slower INTEGER PRIMARY KEY
> AUTOINCREMENT you can't delete the newest inserted row though... how do
> you tell that the row you want to delete is the newest?
It's unclear how much slower INTEGER PRIMARY KEY AUTOINCREMENT is; the
difference may be irrelevant for this use case.
But note that INTEGER PRIMARY KEY columns also autoincrement, so unless
you modify row IDs, the most recent will always be MAX(rowid) (until you
overflow the 64-bit integer key type, anyway).
If you do modify row IDs, you could add a timestamp column that you
touch when adding rows and then delete the row with the most recent
timestamp.
-myk
Neil
> Neil wrote:
>
>> Myk Melez wrote:
>>
>>> DELETE FROM <table> WHERE <autoincrement field> IN (SELECT
>>> <autoincrement field> FROM <table> ORDER BY <autoincrement field>
>>> LIMIT <MAX_URLBAR_HISTORY_ITEMS>);
>>
>> That's not right, that will delete those items, not keep them...
>
> Err, sorry, right. To keep those items, change the operator in the
> outer WHERE clause to NOT IN.
>
>> I think I want DESC LIMIT 1 OFFSET <MAX_URLBAR_HISTORY_ITEMS>;
>
> This will only delete one record, which doesn't sound like what you want.
I think I only ever need to delete one at a time, but your NOT IN way
works too.
>> It's a shame that unless you go for the slower INTEGER PRIMARY KEY
>> AUTOINCREMENT you can't delete the newest inserted row though... how
>> do you tell that the row you want to delete is the newest?
>
> It's unclear how much slower INTEGER PRIMARY KEY AUTOINCREMENT is; the
> difference may be irrelevant for this use case.
>
> But note that INTEGER PRIMARY KEY columns also autoincrement, so
> unless you modify row IDs, the most recent will always be MAX(rowid)
> (until you overflow the 64-bit integer key type, anyway).
The page you linked to claims that deleting the most recent row does Bad
Things (TM)... I don't need to modify row IDs though.
Myk Melez
> The page you linked to claims that deleting the most recent row does Bad
> Things (TM)... I don't need to modify row IDs though.
The only bad thing it does with INTEGER PRIMARY KEY rows is reuse the
row ID of the deleted row for the next inserted row.
But that's only bad if you count on those row IDs (f.e. you store
references to them elsewhere and don't update those references when you
delete the row). Otherwise it's fine.
-myk
Axel Hecht
I fell for "it can read my localstore" before.
I really don't know how to constructively test this, and it just
appeared to me that even the W3C testcases themselves claim to not be
exhaustive. And they mostly test RDF/XML parsing.
The tricky part is loading some datasource into the graph, then
modifying the graph programmatically, and then serializing and parsing
back. At least that's the code path that I regressed before.
To really test this, one has to expose artifacts of RDF (anonymous vs
non-anonymous resources, targets can be pretty much anything) and the
artifacts of RDF/XML (relative URLs in resources, id vs about,
namespaces), and cover those in 'all' graph topologies. 'all' is the
tricky part here, of course. Fuzzing might give confidence, if it's
intelligent enough to actually cover many graph topologies. Unit tests
would be better of course, though I had no clue what exactly the units
would be.
Axel
Benjamin Smedberg
> The tricky part is loading some datasource into the graph, then
> modifying the graph programmatically, and then serializing and parsing
> back. At least that's the code path that I regressed before.
Considering that this parser doesn't do XML serializing at all (by design),
only N-triples, that could be a challenge ;-) The tests I used had an RDFXML
and n-triples graph that were supposed to be equivalent, and compared them.
> To really test this, one has to expose artifacts of RDF (anonymous vs
> non-anonymous resources, targets can be pretty much anything) and the
> artifacts of RDF/XML (relative URLs in resources, id vs about,
> namespaces), and cover those in 'all' graph topologies. 'all' is the
> tricky part here, of course. Fuzzing might give confidence, if it's
> intelligent enough to actually cover many graph topologies. Unit tests
> would be better of course, though I had no clue what exactly the units
> would be.
Well, the set of W3C tests I ran against it may not be "complete", but it is
pretty large. There are some things I'm explicitly not supporting (if I
remember the patch, it's been a while), like relative URIs for resources.
--BDS
Axel Hecht
> Axel Hecht wrote:
>
>> The tricky part is loading some datasource into the graph, then
>> modifying the graph programmatically, and then serializing and parsing
>> back. At least that's the code path that I regressed before.
>
> Considering that this parser doesn't do XML serializing at all (by design),
> only N-triples, that could be a challenge ;-) The tests I used had an RDFXML
> and n-triples graph that were supposed to be equivalent, and compared them.
Hrm. We're talking about data migration here all over. You'd need to
verify that the graphs serialized by the current RDF/XML serializer
don't fall into dataloss when fed to, optimally, both the current
RDF/XML parser and your substitute. Not that I would make any blunt
statements on the success ratio of the current one, anyway, regressions
would be regressions and thus potential dataloss.
Axel
Daniel Kirsch
core code. If I don't want to use it, that's fine, but there are people
who actually understand how it works. They love it and they use it a
lot. Their programs will be broken as soon as RDF support has gone.
If Firefox doesn't use RDF anymore to store any data, that's fine too,
but there are many extension developers and the number of XULRunner
applications is high and will increase.
So please don't drop RDF just because most people don't understand how
to use it (me too btw).
Daniel
Matthew Gertner
Supposedly this should be fixed now.
Benjamin Smedberg
> I simply don't understand why everyone wants RDF to go away from the
> core code. If I don't want to use it, that's fine, but there are people
> who actually understand how it works. They love it and they use it a
> lot. Their programs will be broken as soon as RDF support has gone.
Application authors who want our existing RDF engine could include it in
their application: it just wouldn't be part of the core XR runtime.
> So please don't drop RDF just because most people don't understand how
> to use it (me too btw).
It's not that people don't understand how to use it: it's that our RDF
engine has an extremely poor API and doesn't match up with the actual W3C
RDF specifications.
--BDS
Michael Vincent van Rantwijk, MultiZilla
It that case it should be fixed, not removed, just like *all* that work
that goes into fixing the UI to please the end-user. You guys seem to
ignore the good old group of developers who give everything and try to
please *your* the end-users too!
--
Michael Vincent van Rantwijk
- MultiZilla Project Team Lead
- XUL Boot Camp Staff member (ActiveState Training Partner)
- iPhone Application Developer
Benjamin Smedberg
> It that case it should be fixed, not removed, just like *all* that work
> that goes into fixing the UI to please the end-user. You guys seem to
> ignore the good old group of developers who give everything and try to
> please *your* the end-users too!
Wait, are you proposing that we fix a feature that we don't really need? If
you need it that badly, *you* fix it. There is no free lunch, and this
particular lunch is already moldy and disgusting.
--BDS
Karsten Düsterloh
> It's not that people don't understand how to use it: it's that our RDF
> engine has an extremely poor API
True.
> and doesn't match up with the actual W3C RDF specifications.
But these two points don't justify a removal, they cry for "fix me"!
And, of course, wherever we use RDF now (and we do rely on it rather
heavily in MailNews, but that's a part many folks don't care anyway),
it's useful to look for *faster* alternatives.
But Mossop's results aren't exactly promising here...
And talking about bad API: the mozstorage API isn't a revelation
either.. ;-)
Karsten
--
Feel free to correct my English. :)
Michael Vincent van Rantwijk, MultiZilla
> Michael Vincent van Rantwijk, MultiZilla wrote:
>
>> It that case it should be fixed, not removed, just like *all* that work
>> that goes into fixing the UI to please the end-user. You guys seem to
>> ignore the good old group of developers who give everything and try to
>> please *your* the end-users too!
>
> Wait, are you proposing that we fix a feature that we don't really need?
Wait, you know that there are more than three we's here, right?
> If you need it that badly, *you* fix it.
Right, so you (nothing personal) have a free lunch and others can do the
dishes for you? Arn't we forgetting who is getting paid a huge salary
here, while so many other struggle and do the same kind of work to
please your end users for free?
I know what happens next, like for example that Mozilla will lose major
supporter, their money and search money just because this kind of
attitude is plain wrong. Don't believe me? So where was you during XUL
Boot Camp 2007?
> There is no free lunch, and this
> particular lunch is already moldy and disgusting.
>
> --BDS
Nobody here ever said they want a free lunch, and for your info the
party I am referring to did in fact pay parts of your lunch, and too
long it seems.
Also, without a payed (Google) lunch, you're free time is about to
expire too my friend. You just lost a MAJOR client in the USA/Worldwide
that will no longer use and support the MoFo/MoCo products from 2008 and
on, and I promise you this is going to hurt like hell in terms of
financial support!
Neil Deakin
>
> It that case it should be fixed, not removed,
Why fix it when we can waste two years rewriting history [1], also known
as places? ;)
[1] http://www.joelonsoftware.com/articles/fog0000000069.html
Neil
Axel Hecht
> Benjamin Smedberg aber hob zu reden an und schrieb:
>> It's not that people don't understand how to use it: it's that our RDF
>> engine has an extremely poor API
>
> True.
>
>> and doesn't match up with the actual W3C RDF specifications.
>
> But these two points don't justify a removal, they cry for "fix me"!
>
> And, of course, wherever we use RDF now (and we do rely on it rather
> heavily in MailNews, but that's a part many folks don't care anyway),
> it's useful to look for *faster* alternatives.
> But Mossop's results aren't exactly promising here...
MailNews and its usage of RDF is likely the biggest nail in the coffin
of RDF.
Basically, any attempt to fix parts of RDF so far ended up in "oh, and
rewrite mailnews". It seems to be simpler to say "we'll rip it out", and
see how mailnews deals with that.
> And talking about bad API: the mozstorage API isn't a revelation
> either.. ;-)
Horrifying at best, yeah. I have my own little revelation that I think I
should blog about, I'm just not sure if "rip out SQL" is too aggressive
as a title. I see us doing similar mistakes with SQL as we did with RDF,
and bad APIs is just one part of that. I did blog about the API part
already, see
http://blog.mozilla.com/axel/2007/08/21/rfe-orm-for-mozstorage/.
I didn't talk about the fact that we don't have a SQL design zar
comittee. If we don't fix that one, SQL will turn evil in a few years
from now, and we may end up with another surge to kill a 3-letter acronym.
Anyway, from a migration point of view, there's no continuous path
between the stuff in mozilla/rdf and something that's decent and
attractive to use. At least I don't see any. See my comments in the
other part of this thread on just the dataloss issues, and that's not
even talking about all the unhappy things that mailnews does.
Axel
Axel Hecht
Sadly, a significant part of it is people that don't know how to use it.
That includes me, for much longer than it should have been. Heck, I have
seen em:type before it was sealed. I wouldn't say that I'm done, too.
We just lost a whole slew of know-how with the Netscape death, at least
I hope we did. And those people that knew probably wouldn't have missed
all the trains out there that I did. The whole shift towards js as a
real implementation language went independently from RDF apis, which led
to dead trails like rdfITripleVisitor. That's cute for an addref or two,
but for js, it's just crap. How to uncrap it is something I learned this
year, or maybe just in the last few months. Read iterators/generators,
object mapper architectures, too.
Yeah, the APIs suck and standards support is wonky, but that doesn't
keep mozstorage from anything.
There is a people-problem side.
Axel
Karsten Düsterloh
> MailNews and its usage of RDF is likely the biggest nail in the coffin
> of RDF.
Erm, the fact that MailNews has to use RDF as it is is a point against RDF?!
> Basically, any attempt to fix parts of RDF so far ended up in "oh, and
> rewrite mailnews". It seems to be simpler to say "we'll rip it out", and
> see how mailnews deals with that.
Oh, thank you very much.
>> And talking about bad API: the mozstorage API isn't a revelation
>> either.. ;-)
>
> Horrifying at best, yeah. I have my own little revelation that I think I
> should blog about, I'm just not sure if "rip out SQL" is too aggressive
> as a title. I see us doing similar mistakes with SQL as we did with RDF,
> and bad APIs is just one part of that.
It'd be promising to use SQL instead of Mork for mail summary files at
first glance, but not on the second one anymore.
While this is partly because mail storage access is not as black-boxed
as it should it, the mozstorage "API" (and perf) don't seem to warrant
the effort, imo. It's not that Mork is exceptionally unstable or
something like that...
> I didn't talk about the fact that we don't have a SQL design zar
> comittee. If we don't fix that one, SQL will turn evil in a few years
> from now, and we may end up with another surge to kill a 3-letter acronym.
Yep.
> Anyway, from a migration point of view, there's no continuous path
> between the stuff in mozilla/rdf and something that's decent and
> attractive to use. At least I don't see any.
I don't mind changes if they're for the better.
But this "RDF has to die" debate focuses too heavy on "I don't like it"
than on "we have something better" ('cause we don't!).
Axel Hecht
> Axel Hecht aber hob zu reden an und schrieb:
>> MailNews and its usage of RDF is likely the biggest nail in the coffin
>> of RDF.
>
> Erm, the fact that MailNews has to use RDF as it is is a point against RDF?!
>
Yes, MailNews is the biggest (only?) user of resource factories, which
need to die. Delegates need to die, too. There may be a tad of both in
ldap, but that's pretty lightweight.
Axel
Shawn Wilsher
> It'd be promising to use SQL instead of Mork for mail summary files at
> first glance, but not on the second one anymore.
> While this is partly because mail storage access is not as black-boxed
> as it should it, the mozstorage "API" (and perf) don't seem to warrant
> the effort, imo. It's not that Mork is exceptionally unstable or
> something like that...
OK, with all of these posts complaining about the mozStorage API, I'm
greatly disappointed that nobody has filed any bugs. As far as I
knew, the only real issue with the API was that when binding
parameters is screwy with us using a 0-based index and sqlite using a
1-based index (which I filed, and then people started saying "yeah, I
always wondered why we did that").
I'm not at all sympathetic to complaints about the API if people are
too lazy to file bugs to get it fixed. I can't read minds!
Matthew Gertner
I find it fascinating that people seem to regard RDF as a storage
mechanism (rather than what it is, which is a knowledge representation
framework). There isn't any RDF vs. mozStorage. There's no issue with
storing RDF in a SQL database, and using flat files for storage isn't
any more sensible or efficient for large data volumes just because the
stuff we're storing is serialized RDF.
The more pertinent question, from my perspective, is why use RDF at all?
This isn't to say that we shouldn't support/use RDF, but I'd like to see
a more critical analysis of what benefits this provides. The obvious
answer is either the elegant data model/associated APIs, or
interoperability with existing RDF consumers/providers. I've yet to be
convinced that there is a compelling case to be made for either of
these. In general the reaction from the RDF crowd is that we should
respect web orthodoxy and support the "standard" (actually not a
standard since the W3C has no authority to define one).
Once again, I'm not against RDF per se, but it would be nice to see a
case made for RDF before we move on to a discussion of how usable RDF
support could be achieved.
Matt
Axel Hecht
To me, there are two substantial differences between SQL and RDF:
RDF is loosely typed, SQL is strictly typed.
RDF is storing data in graphs, SQL is storing data in tables.
I don't give a damn about this "knowledge representation framework", and
even less about reasoning engines.
Arguments on "I can store everything in a table" or "... in a labeled
directed graph" are void. I don't care about 'can', there are use cases
for one, and use cases for the other.
APIs can be made awkward for both, and that can be fixed for both.
For SQL, I find it the initial schema design phase much more complicated
than for RDF. Not that it's easy or even documented on how to do that in
RDF, it might actually be better documented for SQL. But you have to
answer way more questions for SQL, like intl considerations (unicode,
string lengths, etc), orthogonality, indices, implementation artifacts
etc.. For RDF it's more of a "who, how, what", and then you may try to
find out if someone else already had the same "how", to reuse their
vocabulary.
Axel
Axel Hecht
https://bugzilla.mozilla.org/show_bug.cgi?id=394732, by the time I knew
more of what I wanted, we were 1.9 frozen, so I found a blog post asking
for volunteers more constructive than a bug. Both would have been
better, we have that now.
Axel
Robert Kaiser
> I find it fascinating that people seem to regard RDF as a storage
> mechanism
I think the main problem is that we are in fact using RDF quite often in
places where a normal DB table is what we want - and that makes people
dislike the whole thing as it's not actually what RDF was made for or
really good at.
I think there are places where RDF is a good solution - and we may even
have such ones in the tree - but it is no database format, though we've
been using it as one for a long time (given the only database format we
supported was Mork, I even see why some people found [mis]using RDF
instead compelling *g*).
Robert Kaiser
Karsten Düsterloh
> The more pertinent question, from my perspective, is why use RDF at all?
It's there, it works, it's XMLish and nothing better has yet been found.
> This isn't to say that we shouldn't support/use RDF, but I'd like to see
> a more critical analysis of what benefits this provides.
Actually, I don't care about RDF as RDF, but for that kind of mechanism
that MailNews uses and which incidently happens to be labelled 'RDF'.
Broken as it might be, I'm more concerned with how broken MailNews will
be *without* it...
> Once again, I'm not against RDF per se, but it would be nice to see a
> case made for RDF before we move on to a discussion of how usable RDF
> support could be achieved.
We could degrade 'our' current RDF to "this is an arcane above-XML-layer
we use internally". ;-)
Pulling the plug of anything in use is no fun without first having
working alternatives.
Robert Sayre
>
> Pulling the plug of anything in use is no fun without first having
> working alternatives.
I don't see anyone claiming that mailnews has to drop RDF. I think we
should drop it from the Firefox distribution, ASAP. Then, the people who
use it can maintain it.
That means we need a JS parser for localstore.rdf, with tests. Of
course, we can't prove that it behaves just like the current RDF code,
just like we can't prove there are no hamburgers on the moon.
- Rob
Philip Chee
> Karsten Düsterloh wrote:
>> Pulling the plug of anything in use is no fun without first having
>> working alternatives.
> I don't see anyone claiming that mailnews has to drop RDF. I think we
> should drop it from the Firefox distribution, ASAP. Then, the people who
> use it can maintain it.
If that is the case then I can breathe a bit easier, but I understood
previous announcements to mean nuking RDF from the CVS completely.
> That means we need a JS parser for localstore.rdf, with tests. Of
> course, we can't prove that it behaves just like the current RDF code,
> just like we can't prove there are no hamburgers on the moon.
Of course not. Everyone knows it's green cheese.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Why yes, they are Bugle Boy beans.
* TagZilla 0.066.6
Benjamin Smedberg
> Actually, I don't care about RDF as RDF, but for that kind of mechanism
> that MailNews uses and which incidently happens to be labelled 'RDF'.
> Broken as it might be, I'm more concerned with how broken MailNews will
> be *without* it...
To repeat sayrer: we are not discussing removing the code entirely. We are
discussing removing the RDF code from the core XULRunner/Firefox runtime.
Applications such as mailnews and any other applications may continue to use
(and maintain) the codebase as they see fit.
--BDS
Axel Hecht
Despite what others said, mailnews should kill at least some of it's
uses of RDF. That's no magic surprise or hidden agenda, see
https://bugzilla.mozilla.org/show_bug.cgi?id=377319#c5.
Axel
Axel Hecht
> Karsten Düsterloh wrote:
>>
>> Pulling the plug of anything in use is no fun without first having
>> working alternatives.
>
> I don't see anyone claiming that mailnews has to drop RDF. I think we
> should drop it from the Firefox distribution, ASAP. Then, the people who
> use it can maintain it.
You haven't been looking.
> That means we need a JS parser for localstore.rdf, with tests. Of
> course, we can't prove that it behaves just like the current RDF code,
> just like we can't prove there are no hamburgers on the moon.
Pigs do fly, it's just a matter of the engine.
Axel
Robert Kaiser
> Despite what others said, mailnews should kill at least some of it's
> uses of RDF.
There's no doubt about this, I think even MailNews people will largely
agree with that (same for Mork), just that they lack the manpower to do
that in the foresseable future, from what I see.
Robert Kaiser
Karsten Düsterloh
> Despite what others said, mailnews should kill at least some of it's
> uses of RDF.
"Should" isn't the problem, manpower *is*.
The point I'm most mad about here is the _way_ of doing such removals:
"Hey, I hate it, let's remove it, let others fix the breakage if they
need it."
"Don't fix it if it ain't broken" does imo include "don't remove it if
someone is using it".
Axel Hecht
> Axel Hecht aber hob zu reden an und schrieb:
>> Despite what others said, mailnews should kill at least some of it's
>> uses of RDF.
>
> "Should" isn't the problem, manpower *is*.
>
> The point I'm most mad about here is the _way_ of doing such removals:
> "Hey, I hate it, let's remove it, let others fix the breakage if they
> need it."
> "Don't fix it if it ain't broken" does imo include "don't remove it if
> someone is using it".
>
It's severely broken, and it has been lingering for years. Thunderbird
manpower claims need to stop being an argument at some point.
Axel
Robert Kaiser
> Thunderbird
> manpower claims need to stop being an argument at some point.
They won't unless the underlying issue, i.e. the manpower itself, gets
fixed in some way.
Robert Kaiser
Myk Melez
> The point I'm most mad about here is the _way_ of doing such removals:
> "Hey, I hate it, let's remove it, let others fix the breakage if they
> need it."
That's not my attitude, and I don't think it's the attitude of others.
Rather, folks are considering the question of what a Mozilla 2 platform
should contain in its core. And our RDF implementation doesn't seem
like a good fit, given that the RDF functionality we've been using is
better provided by other technologies.
> "Don't fix it if it ain't broken" does imo include "don't remove it if
> someone is using it".
One problem is that it is broken. But even if it weren't, "don't remove
it if someone is using it" is not an operative principle of the Moz2
effort. It was a fine principle for the Mozilla 1.x series, where API
compatibility was important, but the whole point of a major version rev
is to be able to break things for the sake of a better platform.
-myk
Mark Banner
> Despite what others said, mailnews should kill at least some of it's
> uses of RDF. That's no magic surprise or hidden agenda, see
> https://bugzilla.mozilla.org/show_bug.cgi?id=377319#c5.
I'd love to kill the address book uses of RDF. However, I still haven't
seen a suitable, easy to use replacement for it.
Essentially, I need to be able to drive a list of address books to
template based elements (menuitems, trees etc) with additional
attributes for querying. It doesn't need to be stored as we store it in
prefs, but I do need to be able to drive updates from a js or c++
component (whichever I feel like ;-) ).
XML sounds possible, but the documentation that I've found so far
doesn't even give me a hint as to where to start. A mozStorage based
implementation (I think possible once the mozStorage template query
processor bug is resolved) sounds possible, but we'd have to drive it
from tables not prefs (I'm not sure which I prefer).
So I don't mind removing RDF from core so that others can maintain it,
but at least give us some reasonable alternatives and documentation so
that we can at least try and pick up something from core if we have the
time/want to.
Standard8
Axel Hecht
I do think that we don't have a up-to-par replacement for XUL templates,
in particular, no alternative offers live UI updates for model changes.
I know that that 'can' be fixed, no idea at which cost or who's signing
up for it, though.
As for mailnews, if you want to stick to RDF for UI, you should start
with moving application logic out of resource objects and into datasources.
Axel
Axel Hecht
Nope. We just need to change priorities, and mozilla 2 is the right
place to do that.
Axel
Axel Hecht
> Benjamin Smedberg wrote:
>> Myk Melez wrote:
>>
>>> The replacement for RDF-for-UI-generation is XML-based templates, for
>>> which incomplete documentation is referenced on the "Firefox 3 for
>>> developers" page:
>>
>> As Neil Deakin says, this is incorrect. If anything, the current
>> replacement
>> for RDF-in-templates is a custom nsIXULTemplateQueryProcessor
>> implementation
>> (which is hard!), or better, somebody can work on a JSObject template
>> engine
>> that could generate UI from a JSON-like JS object structure.
>
> We've done some fairly extensive research into existing template engines
> that might be candidates for a standard Mozilla engine. We looked
> primarily at Python and C++-based solutions. The former are quite cool
> but would require linking to the Python runtime (probably a
> non-starter). Of the C++ solutions, I believe that CTemplate looked most
> promising. That said, the idea of a JS-based engine along the lines of
> existing Python systems (could we take an existing engine and replace
> Python with JS?) sounds very promising. Mozilla should have a proper
> built-in template engine for generating markup.
>
> You can read about our survey here:
> https://krtek.allpeers.com/dokuwiki/doc:func:ui_templates
I have done some reading on those, and from what I heard in other
unrelated discussions, being able to fastload templates would like stay
as a requirement.
As noted in the other leaf of this thread, having live updates on model
changes is a pretty unique feature of our template system, too.
Axel
Robert Kaiser
We are a long way from MailNews devs even looking at Mozilla2, as they
need to get something in shape for 1.9 first, and there's even still a
lot of work to do there. Parallel development for 1.9 and 2 is IMHO not
something that the MailNews team can afford at all.
Robert Kaiser
Axel Hecht
Let's not be too picky about 1.9+ and 2. If you look at brendan's reply,
you'll see that he's much in favour of not having a 1.9+. This subthread
is about whether mailnews can make RDF stick unchanged in Mozilla 2, and
the answer is "no".
Axel
Mark Banner
> I do think that we don't have a up-to-par replacement for XUL templates,
> in particular, no alternative offers live UI updates for model changes.
And that's my biggest complaint - there's no suitable alternative. Most
of the items that are being/have been removed from core that I have seen
are because they are not widely used, or there are acceptable and usable
replacements.
> As for mailnews, if you want to stick to RDF for UI, you should start with moving application logic out of resource objects and into datasources.
As I've already said, I happy not to stick to RDF for address book (if
there was something reasonable, I expect the rest of mailnews could
easily follow as well). I very much doubt we're going to start
rearranging our rdf structures like you suggest - there would be no
point, if we're then going to replace them with something else 6 months
later because core has dumped it and we've got no one to maintain the code.
If Mozilla 2 core is going to be removing items and not giving
acceptable alternatives, then that means we'd better start raising
regression bugs before we start.
Standard8
Karsten Düsterloh
>> I do think that we don't have a up-to-par replacement for XUL
>> templates, in particular, no alternative offers live UI updates for
>> model changes.
>
> And that's my biggest complaint - there's no suitable alternative.
Exactly.
>> As for mailnews, if you want to stick to RDF for UI, you should
>> start with moving application logic out of resource objects and
>> into datasources.
>
> As I've already said, I happy not to stick to RDF for address book
> (if there was something reasonable, I expect the rest of mailnews
> could easily follow as well).
Of course we would - if it's worth the effort.
But rewriting the MailNews world just because something is removed for
being ugly regardless of suitable alternatives is not going to happen -
not because we won't like to do, it's just lack of resources.
(I don't complain! I'm just stating facts. I have a *long* list of stuff
I'd like to do with/in MailNews, I just don't have the time to do it;
and that's a problem almost all here might know. There is a RL outside
Mozilla, you know... ;-) )
Mind you, we still even use libmime, which partly dates back to
Netscape 3!
> I very much doubt we're going to start
> rearranging our rdf structures like you suggest - there would be no
> point, if we're then going to replace them with something else 6
> months later because core has dumped it and we've got no one to
> maintain the code.
Actually, looking at the course of discussion here ("You're using RDF?
Too bad!"), I fear we'll just grab the current RDF code and preserve
under mailnews... :-(
> If Mozilla 2 core is going to be removing items and not giving
> acceptable alternatives, then that means we'd better start raising
> regression bugs before we start.
I wonder who'd care for these bugs.
<sarcasm>The still most voted bug in Bugzilla is MNG.</sarcasm>
Dan Mosedale
> Axel Hecht wrote:
>> I do think that we don't have a up-to-par replacement for XUL
>> templates, in particular, no alternative offers live UI updates for
>> model changes.
>
> And that's my biggest complaint - there's no suitable alternative. Most
> of the items that are being/have been removed from core that I have seen
> are because they are not widely used, or there are acceptable and usable
> replacements.
I think a lot of that depends on your definition of "suitable". The new
ways of driving templates have already been mentioned earlier in this
thread. And at a more basic level, one can certainly update UI
dynamically in an event driven way from JS.
> If Mozilla 2 core is going to be removing items and not giving
> acceptable alternatives, then that means we'd better start raising
> regression bugs before we start.
I believe that the cost of carrying RDF as part of the platform is high,
because it significantly hurts the approachability and maintainability
of code that uses it (I say this just having spent a bunch of time
dealing with the RDF in external helper app service).
Regardless of whether RDF lives on as part of the Moz2 core or not, if
people want to continue to use it, somebody is going to have to sign up
to do the heavy lifting of making it continue to play nice in the Moz2
world. And if it doesn't belong as part of the platform, forcing the
platform maintainers to shoulder that weight doesn't make sense.
If you feel that the methods of updating UI described above are
insufficient for your needs, the way forward here is to propose and
drive agreement on something better for Moz2 that doesn't have the
various problems that RDF does and get someone to sign up to do the
implementation.
Dan
Michael Vincent van Rantwijk, MultiZilla
> Mark Banner wrote:
>> Axel Hecht wrote:
>>> I do think that we don't have a up-to-par replacement for XUL
>>> templates, in particular, no alternative offers live UI updates for
>>> model changes.
>>
>> And that's my biggest complaint - there's no suitable alternative.
>> Most of the items that are being/have been removed from core that I
>> have seen are because they are not widely used, or there are
>> acceptable and usable replacements.
>
> I think a lot of that depends on your definition of "suitable". The new
> ways of driving templates have already been mentioned earlier in this
> thread. And at a more basic level, one can certainly update UI
> dynamically in an event driven way from JS.
I admit, I was in shock at first, but got my first simple RDF->SQLite
port going pretty smoothly. I am now looking at my first nsITreeView
implementation driven by SQLite, to take on a second challenge, because
we will have to do this work sooner or later anyway, but the lack of
documentation is killing me (and my time) not to mention others
struggling with the same issues.
Getting pointers like: "Take a look at places" isn't going to help
people accept SQLite as their RDF replacement, and no, not everybody
lives in irc.mozilla.org
p.s. what is: "The new ways of driving templates"? I can't find it. Sorry.
--
Michael Vincent van Rantwijk
- MultiZilla Project Team Lead
- XUL Boot Camp Staff member (ActiveState Training Partner)
- iPhone Application Developer
Shawn Wilsher
<mv_van_rantw...@yahoo.com> wrote:
> I admit, I was in shock at first, but got my first simple RDF->SQLite
> port going pretty smoothly. I am now looking at my first nsITreeView
> implementation driven by SQLite, to take on a second challenge, because
> we will have to do this work sooner or later anyway, but the lack of
> documentation is killing me (and my time) not to mention others
> struggling with the same issues.
doc page on devmo...
Axel Hecht
I guess he's more talking about
http://wiki.mozilla.org/XUL:Template_Features_in_1.9 and its lack of
further detail. Not sure if http://wiki.mozilla.org/XUL:Templates_Plan
would answer some of them.
Axel
Michael Vincent van Rantwijk, MultiZilla
You mean this page: http://developer.mozilla.org/en/docs/Storage
That's nice as a starter, but what people also/really need are examples
showing them how to replace their UI's driven by RDF tree's and
template's. Answers to questions like; can we still use light weight JS
to build trees and templates, or are templates dead now?
The main problem now is that people have to know where to look (for)
because let's face it, RDF is on the index page but SQLite still not,
and there are no links to the IDL files (which you'll need to look into
for additional info) or any other documentation right now.
So yeah, examples is what people need, and don't give me the we have
examples... look at places, or stop asking people for small test cases
in bug reports ;)
Michael Vincent van Rantwijk, MultiZilla
Right, more food for thought.
Frank Wagner
The discussion about removing RDF from Mozilla surprises, confuses, scares and
frustrates me. The combination of RDF with XUL/XBL makes Mozilla worth looking at
for development and I will try to illustrate that. (btw I use Firefox and
Thunderbird and I'm like both!)
I am not a programmer so I can't say much about the quality of apis or the
implementation in Mozilla (and I probably get some things wrong). I am interested
in the ways we can apply information technology (use the possibilities technology
provides). After long, frustrating years of trying to adopt 'applications' like
Word I try a different approach:
I am looking for personal applications - in contrast to personalized general
applications - that emerge when someone uses available technology in his/her own way.
From this point of view any attempts to move away from RDF to some task or
process specific api is really bad. As far as I can see it Sunbird is an example.
Instead of adding a simple datasource with statements about events I have to
program some provider, kind of hopeless for me (tell me I'm wrong ;) ).
The basic idea is rather simple: On one side I have my resources, that's
everything available to me. On the other side I have views which I use to relate,
compare, validate, evaluate, ... these resources with each other so I can achieve
whatever I want or need to. I work with these resources fx by annotating them,
that them, that is by making and collecting statements from different sources
about these resources. I use these statements to build several different views.
That is what Mozilla is doing in a nutshell, isn't it?!?
Well I do have some problems with and wishes for how things work (named graphs,
fx?, templates can be rather tricky), but the general concepts are nice from my
point of view. Mozilla seen this way provides an environment where people can use
the features it provides - rather than being just another browser-'application'
trying to implement as many as possible ways to navigate the web.
Any comments?
Anyway - thank you for all the good things you are doing/providing :)
Frank
PS: I'm working an a workspace to demonstrate these idea, but things move so
slowly :S . This was a rather short summary. Where would you discuss ideas like
this, if not here?