info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[Compat Data] Data Store API: Handeling environment
11 views
Skip to first unread message
Jeremie Patonnier
Jul 21, 2014, 11:04:16 AM7/21/14
to dev...@lists.mozilla.org, Andrew Overholt, John Whitlock, Luke Crouch, Alicia Spivak
Hi!
This the first follow up e-mail after a long meeting I had with John last
Friday. We discuss many point on the API for the data store, but some of
them seriously needs a wider discussion with all of you.
This first e-mail is about Browser environment.
John suggest we add an environnement entry to the *Browsers* collection:
-
https://github.com/jwhitlock/web-platform-compat/blob/master/api.md#browsers
The intent is to mimic the current segregation we have on MDN with desktop
vs mobile browsers. My opinion is that it is a very fuzzy notion and that
we should not record such information into the DB. I tend to think that
using the Browser name could be good enough if we really needs to make such
distinction (i.e. Safari for Mac vs Safari for iOS) as it is two distinct
browsers. Actually I think it's a fuzzy notion because it is sometimes kind
of arbitrary and it can change over time.
For example, here is the current Firefox ecosystem:
-
- Firefox
- Firefox for Android
- Firefox OS
- Firefox for Firefox OS (Firefox OS' browser)
But there is worst case scenario where mobile means almost nothing. For
example, what about the Android stock browser:
http://slides.com/html5test/the-android-browser
It is very difficult to seriously keep track of each browser on all device
and OS therefor I tend to think we should just use Browsers name for the
most important products and possibly use implementation notes at the
browser level to keep track of the subtleties between similar product.
Similar to that is the question raised by Andrew Overholt a few weeks ago:
Is it possible to know what API are available only in Web Workers? Actually
such question is larger than it looks. Browsers have different internal
environment to run web technologies, with different API available:
- Web content (regular web pages)
- Web Workers
- Browser content (directly inside the browser such as Firefox Add-ons,
Chrome Apps or Safari Extensions)
Plus, they can also have some kind of security/permission model on top of
that (i.e. take a look at Firefox OS).
And there is no guaranty it will not change in the future.
So given all of that, I tend to think we should not keep this linked to the
Browsers collection but simply have dedicated Feature-sets dedicated to
each environnement. However, I know it could make things hard if we want to
make conditional request against some features based on their availability
on some environment for some browsers.
Could it be possible to imagine some king of an heritage system between
browsers? Something like: Browser A is the same as Browser B but Browser B
has feature X differently implemented than Browser A. That could be very
handy for WebKit browsers for examples which are basically all the same but
with subtle build difference (to say the least).
I would love to hear any suggestion you could have to handle all of this
without cluttering the DB model to much (which could make contribution and
maintenance very hard).
Best,
--
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>
This the first follow up e-mail after a long meeting I had with John last
Friday. We discuss many point on the API for the data store, but some of
them seriously needs a wider discussion with all of you.
This first e-mail is about Browser environment.
John suggest we add an environnement entry to the *Browsers* collection:
-
https://github.com/jwhitlock/web-platform-compat/blob/master/api.md#browsers
The intent is to mimic the current segregation we have on MDN with desktop
vs mobile browsers. My opinion is that it is a very fuzzy notion and that
we should not record such information into the DB. I tend to think that
using the Browser name could be good enough if we really needs to make such
distinction (i.e. Safari for Mac vs Safari for iOS) as it is two distinct
browsers. Actually I think it's a fuzzy notion because it is sometimes kind
of arbitrary and it can change over time.
For example, here is the current Firefox ecosystem:
-
- Firefox
- Firefox for Android
- Firefox OS
- Firefox for Firefox OS (Firefox OS' browser)
But there is worst case scenario where mobile means almost nothing. For
example, what about the Android stock browser:
http://slides.com/html5test/the-android-browser
It is very difficult to seriously keep track of each browser on all device
and OS therefor I tend to think we should just use Browsers name for the
most important products and possibly use implementation notes at the
browser level to keep track of the subtleties between similar product.
Similar to that is the question raised by Andrew Overholt a few weeks ago:
Is it possible to know what API are available only in Web Workers? Actually
such question is larger than it looks. Browsers have different internal
environment to run web technologies, with different API available:
- Web content (regular web pages)
- Web Workers
- Browser content (directly inside the browser such as Firefox Add-ons,
Chrome Apps or Safari Extensions)
Plus, they can also have some kind of security/permission model on top of
that (i.e. take a look at Firefox OS).
And there is no guaranty it will not change in the future.
So given all of that, I tend to think we should not keep this linked to the
Browsers collection but simply have dedicated Feature-sets dedicated to
each environnement. However, I know it could make things hard if we want to
make conditional request against some features based on their availability
on some environment for some browsers.
Could it be possible to imagine some king of an heritage system between
browsers? Something like: Browser A is the same as Browser B but Browser B
has feature X differently implemented than Browser A. That could be very
handy for WebKit browsers for examples which are basically all the same but
with subtle build difference (to say the least).
I would love to hear any suggestion you could have to handle all of this
without cluttering the DB model to much (which could make contribution and
maintenance very hard).
Best,
--
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>
Andrew Overholt
Jul 21, 2014, 11:42:25 AM7/21/14
to Jeremie Patonnier, dev...@lists.mozilla.org, John Whitlock, Luke Crouch, Alicia Spivak
Hi,
On Mon 21 Jul 2014 11:04:16 AM EDT, Jeremie Patonnier wrote:
> It is very difficult to seriously keep track of each browser on all
> device and OS therefor I tend to think we should just use Browsers
> name for the most important products and possibly use implementation
> notes at the browser level to keep track of the subtleties between
> similar product.
This sounds good to me.
> Could it be possible to imagine some king of an heritage system
> between browsers? Something like: Browser A is the same as Browser B
> but Browser B has feature X differently implemented than Browser A.
I was going to ask if it's possible to store features by engine
(+version) instead of by browser but that seems just as complex,
especially given the Android browser presentation you linked to :)
Andrew
On Mon 21 Jul 2014 11:04:16 AM EDT, Jeremie Patonnier wrote:
> It is very difficult to seriously keep track of each browser on all
> device and OS therefor I tend to think we should just use Browsers
> name for the most important products and possibly use implementation
> notes at the browser level to keep track of the subtleties between
> similar product.
> Could it be possible to imagine some king of an heritage system
> between browsers? Something like: Browser A is the same as Browser B
> but Browser B has feature X differently implemented than Browser A.
(+version) instead of by browser but that seems just as complex,
especially given the Android browser presentation you linked to :)
Andrew
John Whitlock
Jul 22, 2014, 5:52:08 PM7/22/14
to Jeremie Patonnier, Andrew Overholt, dev...@lists.mozilla.org, Luke Crouch, Alicia Spivak
I've converted the draft API docs to reStructuredText at Luke's request.
Here's the new location of the rendered docs:
http://web-platform-compat.readthedocs.org/en/latest/draft/resources.html#browsers
and the source in github:
https://github.com/jwhitlock/web-platform-compat/blob/master/docs/draft/resources.rst#browsers
I've also been thinking if there is a way to classify browsers that allows
for very detailed scenarios ('This is Firefox 30 on Windows 8 with this set
of active plugins') that may be needed for automated testing, but then
allow that data to be rolled up to more generic names ('Firefox 30 on
Windows', 'Firefox 30', 'Firefox'). Maybe merging the ideas of
browser-versions and browsers would do it. I'm not sure enough to propose
it.
Maybe a way to add in web worker data is to add the concept of a 'context'.
A particular browser would support one or more contexts ('web content',
'web workers', 'extension context'). Would we eventually get broad enough
to include information about node.js alongside other JS features? Not sure
I want to create the grand schema for the whole world yet.
John
Here's the new location of the rendered docs:
http://web-platform-compat.readthedocs.org/en/latest/draft/resources.html#browsers
and the source in github:
https://github.com/jwhitlock/web-platform-compat/blob/master/docs/draft/resources.rst#browsers
I've also been thinking if there is a way to classify browsers that allows
for very detailed scenarios ('This is Firefox 30 on Windows 8 with this set
of active plugins') that may be needed for automated testing, but then
allow that data to be rolled up to more generic names ('Firefox 30 on
Windows', 'Firefox 30', 'Firefox'). Maybe merging the ideas of
browser-versions and browsers would do it. I'm not sure enough to propose
it.
Maybe a way to add in web worker data is to add the concept of a 'context'.
A particular browser would support one or more contexts ('web content',
'web workers', 'extension context'). Would we eventually get broad enough
to include information about node.js alongside other JS features? Not sure
I want to create the grand schema for the whole world yet.
John
> It is very difficult to seriously keep track of each browser on all device
> and OS therefor I tend to think we should just use Browsers name for the
> most important products and possibly use implementation notes at the
> browser level to keep track of the subtleties between similar product.
>
> and OS therefor I tend to think we should just use Browsers name for the
> most important products and possibly use implementation notes at the
> browser level to keep track of the subtleties between similar product.
>
> Similar to that is the question raised by Andrew Overholt a few weeks ago:
> Is it possible to know what API are available only in Web Workers? Actually
> such question is larger than it looks. Browsers have different internal
> environment to run web technologies, with different API available:
>
> - Web content (regular web pages)
> - Web Workers
> - Browser content (directly inside the browser such as Firefox
> Add-ons, Chrome Apps or Safari Extensions)
>
> Plus, they can also have some kind of security/permission model on top of
> that (i.e. take a look at Firefox OS).
>
> And there is no guaranty it will not change in the future.
>
> So given all of that, I tend to think we should not keep this linked to
> the Browsers collection but simply have dedicated Feature-sets dedicated to
> each environnement. However, I know it could make things hard if we want to
> make conditional request against some features based on their availability
> on some environment for some browsers.
>
> Is it possible to know what API are available only in Web Workers? Actually
> such question is larger than it looks. Browsers have different internal
> environment to run web technologies, with different API available:
>
> - Web content (regular web pages)
> - Web Workers
> - Browser content (directly inside the browser such as Firefox
> Add-ons, Chrome Apps or Safari Extensions)
>
> Plus, they can also have some kind of security/permission model on top of
> that (i.e. take a look at Firefox OS).
>
> And there is no guaranty it will not change in the future.
>
> So given all of that, I tend to think we should not keep this linked to
> the Browsers collection but simply have dedicated Feature-sets dedicated to
> each environnement. However, I know it could make things hard if we want to
> make conditional request against some features based on their availability
> on some environment for some browsers.
>
> Could it be possible to imagine some king of an heritage system between
> browsers? Something like: Browser A is the same as Browser B but Browser B
> browsers? Something like: Browser A is the same as Browser B but Browser B
Luke Crouch
Jul 23, 2014, 9:46:02 AM7/23/14
to John Whitlock, Jeremie Patonnier, Andrew Overholt, dev...@lists.mozilla.org, Alicia Spivak
On 7/22/14 4:52 PM, John Whitlock wrote:
> I've converted the draft API docs to reStructuredText at Luke's
> request. Here's the new location of the rendered docs:
>
> http://web-platform-compat.readthedocs.org/en/latest/draft/resources.html#browsers
>
> and the source in github:
>
> https://github.com/jwhitlock/web-platform-compat/blob/master/docs/draft/resources.rst#browsers
>
> I've also been thinking if there is a way to classify browsers that
> allows for very detailed scenarios ('This is Firefox 30 on Windows 8
> with this set of active plugins') that may be needed for automated
> testing, but then allow that data to be rolled up to more generic
> names ('Firefox 30 on Windows', 'Firefox 30', 'Firefox'). Maybe
> merging the ideas of browser-versions and browsers would do it. I'm
> not sure enough to propose it.
>
> Maybe a way to add in web worker data is to add the concept of a
> 'context'. A particular browser would support one or more contexts
> ('web content', 'web workers', 'extension context'). Would we
> eventually get broad enough to include information about node.js
> alongside other JS features? Not sure I want to create the grand
> schema for the whole world yet.
later, I say we punt it for a future iteration.
Anyone opposed?
-L
>
> John
>
>
> On Mon, Jul 21, 2014 at 10:04 AM, Jeremie Patonnier
> <jeremie....@gmail.com <mailto:jeremie....@gmail.com>> wrote:
>
> Hi!
>
> This the first follow up e-mail after a long meeting I had with
> John last Friday. We discuss many point on the API for the data
> store, but some of them seriously needs a wider discussion with
> all of you.
>
> This first e-mail is about Browser environment.
>
> John suggest we add an environnement entry to the *Browsers*
> collection:
>
>
> The intent is to mimic the current segregation we have on MDN with
> desktop vs mobile browsers. My opinion is that it is a very fuzzy
> notion and that we should not record such information into the DB.
> I tend to think that using the Browser name could be good enough
> if we really needs to make such distinction (i.e. Safari for Mac
> vs Safari for iOS) as it is two distinct browsers. Actually I
> think it's a fuzzy notion because it is sometimes kind of
> arbitrary and it can change over time.
>
> For example, here is the current Firefox ecosystem:
>
> *
> The intent is to mimic the current segregation we have on MDN with
> desktop vs mobile browsers. My opinion is that it is a very fuzzy
> notion and that we should not record such information into the DB.
> I tend to think that using the Browser name could be good enough
> if we really needs to make such distinction (i.e. Safari for Mac
> vs Safari for iOS) as it is two distinct browsers. Actually I
> think it's a fuzzy notion because it is sometimes kind of
> arbitrary and it can change over time.
>
> For example, here is the current Firefox ecosystem:
>
>
>
> * Firefox
> * Firefox for Android
> * Firefox OS
> * Firefox for Firefox OS (Firefox OS' browser)
>
> But there is worst case scenario where mobile means almost
> nothing. For example, what about the Android stock browser:
> http://slides.com/html5test/the-android-browser
>
> It is very difficult to seriously keep track of each browser on
> all device and OS therefor I tend to think we should just use
> Browsers name for the most important products and possibly use
> implementation notes at the browser level to keep track of the
> subtleties between similar product.
>
> Similar to that is the question raised by Andrew Overholt a few
> weeks ago: Is it possible to know what API are available only in
> Web Workers? Actually such question is larger than it looks.
> Browsers have different internal environment to run web
> technologies, with different API available:
>
> * Web content (regular web pages)
> But there is worst case scenario where mobile means almost
> nothing. For example, what about the Android stock browser:
> http://slides.com/html5test/the-android-browser
>
> It is very difficult to seriously keep track of each browser on
> all device and OS therefor I tend to think we should just use
> Browsers name for the most important products and possibly use
> implementation notes at the browser level to keep track of the
> subtleties between similar product.
>
> Similar to that is the question raised by Andrew Overholt a few
> weeks ago: Is it possible to know what API are available only in
> Web Workers? Actually such question is larger than it looks.
> Browsers have different internal environment to run web
> technologies, with different API available:
>
> * Web Workers
> * Browser content (directly inside the browser such as Firefox
> Add-ons, Chrome Apps or Safari Extensions)
>
> Plus, they can also have some kind of security/permission model on
> top of that (i.e. take a look at Firefox OS).
>
> And there is no guaranty it will not change in the future.
>
> So given all of that, I tend to think we should not keep this
> linked to the Browsers collection but simply have dedicated
> Feature-sets dedicated to each environnement. However, I know it
> could make things hard if we want to make conditional request
> against some features based on their availability on some
> environment for some browsers.
>
> Could it be possible to imagine some king of an heritage system
> between browsers? Something like: Browser A is the same as Browser
> B but Browser B has feature X differently implemented than Browser
> A. That could be very handy for WebKit browsers for examples which
> are basically all the same but with subtle build difference (to
> say the least).
>
> I would love to hear any suggestion you could have to handle all
> of this without cluttering the DB model to much (which could make
> contribution and maintenance very hard).
>
> Best,
> --
> Jeremie
> .............................
> Web : http://jeremie.patonnier.net <http://jeremie.patonnier.net/>
>
> Plus, they can also have some kind of security/permission model on
> top of that (i.e. take a look at Firefox OS).
>
> And there is no guaranty it will not change in the future.
>
> So given all of that, I tend to think we should not keep this
> linked to the Browsers collection but simply have dedicated
> Feature-sets dedicated to each environnement. However, I know it
> could make things hard if we want to make conditional request
> against some features based on their availability on some
> environment for some browsers.
>
> Could it be possible to imagine some king of an heritage system
> between browsers? Something like: Browser A is the same as Browser
> B but Browser B has feature X differently implemented than Browser
> A. That could be very handy for WebKit browsers for examples which
> are basically all the same but with subtle build difference (to
> say the least).
>
> I would love to hear any suggestion you could have to handle all
> of this without cluttering the DB model to much (which could make
> contribution and maintenance very hard).
>
> Best,
> --
> Jeremie
> .............................
> Twitter : @JeremiePat <http://twitter.com/JeremiePat>
>
>
--
Q: Why is this email five sentences or less?
A: http://five.sentenc.es
Andrew Overholt
Jul 23, 2014, 9:55:07 AM7/23/14
to Luke Crouch, John Whitlock, dev...@lists.mozilla.org, Jeremie Patonnier, Alicia Spivak
On Wed 23 Jul 2014 09:46:02 AM EDT, Luke Crouch wrote:
>
> On 7/22/14 4:52 PM, John Whitlock wrote:
>> I've converted the draft API docs to reStructuredText at Luke's
>> request. Here's the new location of the rendered docs:
>>
>> http://web-platform-compat.readthedocs.org/en/latest/draft/resources.html#browsers
>>
>> and the source in github:
>>
>> https://github.com/jwhitlock/web-platform-compat/blob/master/docs/draft/resources.rst#browsers
>>
>> I've also been thinking if there is a way to classify browsers that
>> allows for very detailed scenarios ('This is Firefox 30 on Windows 8
>> with this set of active plugins') that may be needed for automated
>> testing, but then allow that data to be rolled up to more generic
>> names ('Firefox 30 on Windows', 'Firefox 30', 'Firefox'). Maybe
>> merging the ideas of browser-versions and browsers would do it. I'm
>> not sure enough to propose it.
>>
>> Maybe a way to add in web worker data is to add the concept of a
>> 'context'. A particular browser would support one or more contexts
>> ('web content', 'web workers', 'extension context'). Would we
>> eventually get broad enough to include information about node.js
>> alongside other JS features? Not sure I want to create the grand
>> schema for the whole world yet.
>
> +1 this seems like feature-creep for a v1. So long as we can add it
> later, I say we punt it for a future iteration.
>
> Anyone opposed?
worker. It's one of the top things people ask me alongside "what APIs
are available in what version of {Firefox|Firefox OS|Firefox for
Android}?".
Luke Crouch
Jul 23, 2014, 10:14:36 AM7/23/14
to Andrew Overholt, John Whitlock, dev...@lists.mozilla.org, Jeremie Patonnier, Alicia Spivak
Yeah - capturing contextual compatibility will be very valuable.
(Especially if ServiceWorkers will have separate execution context.)
I want to make sure we do it all right, without cutting any corners to
finish and launch v1.
So, I propose we answer the "what APIs are available in what versions of
..." questions in v1, and answer the questions about contexts in v2.
Sound good?
-L
(Especially if ServiceWorkers will have separate execution context.)
I want to make sure we do it all right, without cutting any corners to
finish and launch v1.
So, I propose we answer the "what APIs are available in what versions of
..." questions in v1, and answer the questions about contexts in v2.
Sound good?
-L
Andrew Overholt
Jul 23, 2014, 10:15:37 AM7/23/14
to Luke Crouch, John Whitlock, dev...@lists.mozilla.org, Jeremie Patonnier, Alicia Spivak
WFM :)
John Whitlock
Jul 23, 2014, 12:39:13 PM7/23/14
to Andrew Overholt, dev...@lists.mozilla.org, Jeremie Patonnier, Luke Crouch, Alicia Spivak
Andrew,
On Wed, Jul 23, 2014 at 8:55 AM, Andrew Overholt <over...@mozilla.com>
wrote:
features for determining the variances in data. Can you give me an example
of where you'd want information about availability in web workers?
This page seems like a good overview, probably written for this use case:
https://developer.mozilla.org/en-US/docs/Web/API/Worker/Functions_and_classes_available_to_workers
But, when you drill down to specific API features, web workers are not
mentioned at all:
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
In an ideal world, how would a developer with an interest in web workers
use the site? How would the interface change?
John
On Wed, Jul 23, 2014 at 8:55 AM, Andrew Overholt <over...@mozilla.com>
wrote:
>
> I really think we need to capture the availability of something in a
> worker. It's one of the top things people ask me alongside "what APIs are
> available in what version of {Firefox|Firefox OS|Firefox for Android}?".
>
I'm very new to the world of web workers, and I've been focusing on CSS
> I really think we need to capture the availability of something in a
> worker. It's one of the top things people ask me alongside "what APIs are
> available in what version of {Firefox|Firefox OS|Firefox for Android}?".
>
features for determining the variances in data. Can you give me an example
of where you'd want information about availability in web workers?
This page seems like a good overview, probably written for this use case:
https://developer.mozilla.org/en-US/docs/Web/API/Worker/Functions_and_classes_available_to_workers
But, when you drill down to specific API features, web workers are not
mentioned at all:
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
In an ideal world, how would a developer with an interest in web workers
use the site? How would the interface change?
John
Andrew Overholt
Jul 23, 2014, 1:38:30 PM7/23/14
to John Whitlock, dev...@lists.mozilla.org, Jeremie Patonnier, Luke Crouch, Alicia Spivak
Hi,
On Wed 23 Jul 2014 12:39:13 PM EDT, John Whitlock wrote:
> I'm very new to the world of web workers, and I've been focusing on
> CSS features for determining the variances in data. Can you give me
> an example of where you'd want information about availability in web
> workers?
After speaking with someone just now I think it's easiest if we just
special-case API availability in workers and note it manually or
something. There aren't going to be too many so having some raw text
field with "available in workers" or something that we can query for if
we want to generate a table of all APIs available in workers would be
perfectly fine.
Sorry for throwing a wrench in the works (I typed "workers" the first
time) here :)
> This page seems like a good overview, probably written for this use case:
>
> https://developer.mozilla.org/en-US/docs/Web/API/Worker/Functions_and_classes_available_to_workers
Yes, that's most likely perfectly acceptable. Thanks for reminding me
of its existence.
> https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
>
> In an ideal world, how would a developer with an interest in web
> workers use the site? How would the interface change?
I imagine it'd be an additional data point in the "Browser
compatibility" table near the bottom of the XHR page you reference.
Thanks again,
Andrew
On Wed 23 Jul 2014 12:39:13 PM EDT, John Whitlock wrote:
> I'm very new to the world of web workers, and I've been focusing on
> CSS features for determining the variances in data. Can you give me
> an example of where you'd want information about availability in web
> workers?
special-case API availability in workers and note it manually or
something. There aren't going to be too many so having some raw text
field with "available in workers" or something that we can query for if
we want to generate a table of all APIs available in workers would be
perfectly fine.
Sorry for throwing a wrench in the works (I typed "workers" the first
time) here :)
> This page seems like a good overview, probably written for this use case:
>
> https://developer.mozilla.org/en-US/docs/Web/API/Worker/Functions_and_classes_available_to_workers
of its existence.
> https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
>
> In an ideal world, how would a developer with an interest in web
> workers use the site? How would the interface change?
compatibility" table near the bottom of the XHR page you reference.
Thanks again,
Andrew
Jeremie Patonnier
Jul 23, 2014, 2:57:58 PM7/23/14
to Andrew Overholt, John Whitlock, Alicia Spivak, Luke Crouch, dev...@lists.mozilla.org
Hi!
The real first use of such information will be to display a list of the
feature available on WebWorkers, crossed with browser support. Same for
Firefox OS permission, same for Gecko internal API, same for Add-ons, and
so on.
To do this we can easily use Feature-sets for a v1. If we get more complexe
use cases after launch, we will examine them to see what need to evolve in
our DB schema. Until then, I really think we can live with Feature-sets for
this.
++
Jeremie
Twitter : @JeremiePat <http://twitter.com/JeremiePat>
The real first use of such information will be to display a list of the
feature available on WebWorkers, crossed with browser support. Same for
Firefox OS permission, same for Gecko internal API, same for Add-ons, and
so on.
To do this we can easily use Feature-sets for a v1. If we get more complexe
use cases after launch, we will examine them to see what need to evolve in
our DB schema. Until then, I really think we can live with Feature-sets for
this.
++
Jeremie
0 new messages