[widgetsapi] reference to WebIDL

[Yves Lafon]

Hi,
In the PR [1], the text referencing WebIDL is not using one of the three 
conformance clauses defined in WebIDL [2].


Could
This specification uses [WebIDL] to specify application programming 
interfaces. be clarified using one of the proposed wordings from WebIDL?

(likely 'Conforming IDL Fragments' per reading of the spec).
Thanks,

[1] http://www.w3.org/TR/2012/PR-widgets-apis-20120522/
[2] http://www.w3.org/TR/WebIDL/#conformance

--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

Re: [widgetsapi] reference to WebIDL

[Yves Lafon]

On Tue, 30 Jul 2013, Marcos Caceres wrote:





On Monday, July 29, 2013 at 9:15 PM, Yves Lafon wrote:


Hi,
In the PR [1], the text referencing WebIDL is not using one of the three
conformance clauses defined in WebIDL [2].

Could
This specification uses [WebIDL] to specify application programming
interfaces. be clarified using one of the proposed wordings from WebIDL?
(likely 'Conforming IDL Fragments' per reading of the spec).
Thanks,




Sure, I can add that if you think it will be helpful.


Yes, that would be helpful (hence the report), thanks.

--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

Re: [widgetsapi] reference to WebIDL

[Yves Lafon]

On Tue, 30 Jul 2013, Marcos Caceres wrote:


On Tuesday, July 30, 2013 at 2:20 PM, Yves Lafon wrote:


Yes, that would be helpful (hence the report), thanks.


Done. Spec now sez:
Implementations that use ECMAScript to implement the APIs defined in this 
specification must implement them in a manner consistent with the ECMAScript Bindings 
defined in the Web IDL specification [WebIDL], as this specification uses that 
specification and terminology.




Whoops. Seems I misunderstood. The spec actually now says:
The IDL blocks in this specification are conforming IDL fragments as defined by the 
WebIDL specification.


Thanks, indeed the CR-PR transition was made with a test suite that was 
linked to this WebIDL reference, and not the other one.


That said, if you have tests and better, a report for a stricter 
conformance to WebIDL, it would be good to highlight them.

Cheers,

--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

Re: [admin] Should WebApps' HTML Templates spec be published as a WG Note?

[Yves Lafon]

On Fri, 7 Mar 2014, Arthur Barstow wrote:


On 2/27/14 12:10 PM, ext Arthur Barstow wrote:

On 2/27/14 11:41 AM, ext Rafael Weinstein wrote:

What do you recommend?

It seems a little heavy-handed to kill it or gut it. What about putting a 
big-red warning at the top that it has been merged to HTML and no longer 
has normative weight.


I don't have a strong preference now and would like to hear from others. 
The above do have different +/-.


I think the principle of least surprise (`follow your nose`) indicates 
navigating to the ED would redirect to the HTML spec. It seems like the 
worst case scenario is for the contents of the ED to be inconsistent with 
HTML.


Rafael, All - having received no additional feedback and only voices of 
support for publishing a WG Note, the main questions seem to be: 1) whether 
the Note should be gutted (f.ex. see [1]) or not; 2) should the ED be gutted 
too.


Although I agree gutting the Note would be a bit heavy-handed as you say, 
it does eliminate the possibility of the contents being different than 
HTMLWG's version. As such, I prefer gutting both the Note and the ED and 
adding a prominent warning plus a link to HTML. For example, borrowing from 
[1], adding something like to the Status of This Document section:


[[
strongWork on this document has been discontinued and it should not be 
referenced or used as a basis for implementation. The features previously 
specified in this document are now specified in a 
href=http://www.w3.org/TR/html5/scripting-1.html#the-template-element;HTML5/a./strong

]]

WDYT?


SGTM, not gutting it has a higher risk of people looking at the wrong doc.

--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

[April2014Meeting] Draft minutes for April 11

[Yves Lafon]

The Draft minutes from WebApps' April 11 f2f meeting are at the
following and copied below:

http://www.w3.org/2014/04/11-webapps-minutes.html

Corrections, comments, etc., are welcome.

Thanks very much to the various scribes and special thanks to Kris for 
handing me the missing minutes.



W3C

- DRAFT -

WebApps f2f Meeting (San Jose CA US)

11 Apr 2014

Agenda

See also: IRC log

Attendees

Present
anssik, [Paypal], +1.301.460., Arnaud_Braud, Takeshi_Yoshino, krisk, 
dglazkov, israel, hilerio, Art_Barstow, Anssi_Kostiainen, Ali_Alabbas, 
Yves_Lafon, Chris_Wilson, israel_hilerio, Feras_Moussa, MichaelTmSmith, 
John_Hazen, Matt_Falkenhagen, Ben_Peters, Adrian_Bateman, Hayato_Ito, 
Zhiqiang_Zhang, Olivier_Potonniee, Gene_Lian, Jungkee_Song, Maciej, 
Laszlo_Gombos, Alex_Russell

Regrets
Chair
ArtB
Scribe
Art, israelh, Ali, krisk, Yves, BenjamP, slightlyoff
Contents

Topics
Web Components
Custom Elements
Shadow Dom
imports
conclusion
Summary of Action Items
ArtB ScribeNick: ArtB
scribe Scribe: Art
dglazkov 
http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0074.html

smaug hello all
Web Components

adrianba scribe: israelh
dglazkov: Would like to break down discussion into three topics: Shadow 
DOM, Custom Elements, and HTML Imports
... Shadow DOM is the more interesting. Let's pick which one we want to 
discuss first.

... Start with Custom Elements ?
... Shadow DOM after that?
... Custom elements is in first draft

ArtB 
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html 
- Custom Elements Editor's Draft

dglazkov https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578
dglazkov: And interesting topic to start with 24578 buhg
... Registering a register primitive
... Having the ability to expose internal attributes on Customer elements 
allow you to clone it, assing it to a different document


ArtB https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567#c69 - Anne's 
comment #69 for bug 20567
dglazkov: The idea is that when an element is adopted from one doc to 
another, and as an an author of the element you will get a callback that 
allows you to reason about the attribute being used in other elements
... also, the idea that you could use the registry as a way to scope the 
element names.
... a web developer has a sub-tree in their document and would like to 
parse their specific elements from the local registry. Having a scoping 
concept would be very useful for them. However, if you want to rountrip 
when coming back form the parse you would have problems
... because when you serialize the tree the parse would have no idea of 
where that element came from, thus surprising.
... I would like to introduce the registry concept into the spec and see 
where it goes from there.

... I want to allow allowNode callback to reason about registries.
... I would like to get everyone's opinion about it.

rniwa: What is the use case for the callback.

dglazkov: deeper into this subject. IE and FF have a behavior that is 
different from blink and WebKit and their prototype when it is adopted 
from another doc.
... IE and FF when you are adopted from one doc to another, you loose your 
old prototypes. Blink and WebKit don't do that.

... there is disagrements whether this should be on spec.
... the callback we are discussing provides a mechanism to allow elements 
to update the prototypes dynamically. Thus, becoming and implementation 
detail instead of part of the spec.


rniwa: it might be more useful to standardize the UA behaviors instead of 
putting this on the hands of the devs.


dglazkov: for custom elements this decision is not so clear. It is not 
always clear what is the right behavior. Specially if the definintion of 
my element is not defined on the new environment.
... element foo may colide with a different definition of another element 
foo on that document.


rniwa: it seems strange that each doc would behave diff on each 
environment. It doesn't allow you to reason about the custom element on 
the environment that is being used.


dglazkov: this seems bad if you don't have the ability to reason about the 
custom elements diff.


adrianba: it would be bad.

rniwa: it seems like we need to figure out how we can guarantee that the 
custom element keeps the same information across document. Maybe this is 
the issue.


dglazkov: that is what registers let you do. You can look at the registry 
and reason about this.


rniwa: potentially you can have a global map for each page. that checks if 
the definition of the class has been raised and possibly rejected. Some 
type of consistency check.
... we probably don't want to reason about having different custom 
elements that are of the same expected type.


dglazkov: the thing is that it doesn't have to be the case, the problem is 
that the scenario could happen and we need to figure out how to deal with 
this.


rniwa: for ex. you can imagine the registry happening about all in one 
script context, within one navigation.

[admin] Positive Work Environment Framework now in effect

[Yves Lafon]

-- Forwarded message --
Date: Thu, 23 Oct 2014 19:56:30 +0200
From: Coralie Mercier cora...@w3.org
To: w3c-ac-fo...@w3.org
Cc: cha...@w3.org
Subject: Positive Work Environment Framework now in effect
Resent-Date: Thu, 23 Oct 2014 17:56:45 +
Resent-From: cha...@w3.org


Dear Advisory Committee Representative,
Chairs,

The Positive Work Environment Task Force [1] is pleased to announce, with 
approval by W3C management and support from the Advisory Board, that the 
following guidelines are now in effect and govern our work environment:


 Code of Ethics and Professional Conduct:
 http://www.w3.org/Consortium/cepc/

 Procedures to assist all parties in case of issues:
 http://www.w3.org/Consortium/pwe/#Procedures


W3C is a growing and global community where participants choose to work 
together, and in that process experience differences in language, location, 
nationality, and experience.


Our Code of Ethics and Professional Conduct defines principles for respectful 
treatment within the W3C community, and it promotes high standards of 
professional practice. It also provides a benchmark for self evaluation and 
acts as a vehicle for better identity of the organization which celebrates its 
20th anniversary this month.


This code, complemented by a set of Procedures, applies to any member of the 
W3C community ? staff, members, invited experts, participants in W3C meetings, 
W3C teleconferences, W3C mailing lists, W3C conference or W3C functions, etc.



Comments should be sent to public-...@w3.org which will be publicly archived 
[2]. The Member task force [1] remains chartered to handle the next revisions 
of the documents. If you are interested in joining it, please contact Coralie 
Mercier cora...@w3.org or Daniel Dardailler dani...@w3.or, co-chairs of the 
task force.



Coralie Mercier, W3C Communications

[1] https://www.w3.org/2011/07/Positive-Work-Environment-TF.html
[2] http://lists.w3.org/Archives/Public/public-pwe/


[Bcc: public-...@w3.org, member-pw...@w3.org]


--
Coralie Mercier  -  W3C Communications Team  -  http://www.w3.org
mailto:cora...@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/

Re: Help with WebIDL v1?

[Yves Lafon]

On Mon, 1 Dec 2014, Boris Zbarsky wrote:


On 12/1/14, 1:49 PM, Travis Leithead wrote:
I believe so; this will give many specs a baseline WebIDL document to point 
to in their references at the very least. Many specs don't rely on the more 
advanced feature set being defined in WebIDL Second Edition.


Here's the problem.

As of today, v2 is not just v1 plus some more features.  They actually have 
some disagreements on how identical IDL syntactic constructs are handled. 
For example, sequence behavior is different: in v1 a sequence has magic for 
platform array objects and the gets the length property and goes from 0 to 
length, while in v2 a sequence is an iterable and uses the ES6 iterator 
protocol.


Pretty much like refactoring XHR using Fetch or not. Most implementations 
will most probably move to the latest version, but the external interface 
will be the same. In the case of Sequence, the ES binding says in the two 
versions IDL sequenceT values are represented by ECMAScript Array 
values.


The option 2 you outline seems best here, the syntax is considered as 
stable (well, can be expanded, things can be declared obsolete, but there 
won't be breaking changes), but implementations (as in the es binding 
algorithms) may change to match the evolution of the underlying language.


Or another example: in v1 having an indexed getter implies nothing about 
being iterable, but in v2 it implies ES6 iterability.


This is an example of v1 plus one feature.

More generally, v1 is pretty much defined in ES5 terms, while v2 is aiming 
for closer convergence with ES6.


What happens when a spec uses a sequence argument and references v1? Are UAs 
supposed to implement the v1 behavior or v2 behavior?


However, let's not hijack this thread; I'd love to hear what the next steps 
are for moving this v1 forward.


I think that actually depends on how we want to handle the problem I describe 
above.


Some obvious options are:

1)  Backport all behavior changes from v2 to v1 so they agree on the set of 
syntactic constructs supported by v1.  This makes v1 depend on ES6, which I 
understood to be a non-goal (or perhaps even anti-goal, given ES6 is not 
finalized yet?  But it's close).


2)  Treat v1 as a syntax spec (with v2 a superset of the syntax) and 
explicitly say somewhere in v1 that v2 can redefine the behavior.  Not sure 
how happy people referencing v1 will be with that.


Other options?


Another option would be to define only the syntax and leave the bindings 
to v2 only, but it wouldn't help much for testing.


--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

Re: WebIDL Plans

[Yves Lafon]

 On 10 Apr 2015, at 18:49, Boris Zbarsky bzbar...@mit.edu wrote:
 
 On 4/10/15 8:53 AM, Yves Lafon wrote:
   * Everything from old v1 expect ArrayClass which is not used, nor 
 implemented anywhere.
 
 It's implemented in Gecko and used for both DOMRectList and MediaList in 
 Gecko, fwiw.
 
 I'm not saying we should include it, just correcting the factual statement.

I remember ArrayClass removed from NodeList for the reason of lack of 
implementations, and even plans for implementation, glad to see it’s not dead, 
and I indeed missed CSSOM when I checked what parts of IDL was used in some 
specifications. At least it means there is no need to remove ArrayClass from 
the edcopy :)


   * Add PromiseT, Iterators, NewObject, Dictionary constructors, Buffer 
 types (USVString and ByteString as well, depending on their  status)
 
 This is pretty hard to evaluate for me coming from the perspective of knowing 
 what's in v2.  Which things are _not_ included then? maplike/setlike, 
 right?  Anything else?

Currently maplike/setlike/ RegExp [Unscopeable] [PrimaryGlobal] [ImplicitThis], 
most probably iterable. But of course this is also subject to the number of 
bugs attached to them, issues with test etc... So many things will still be 
considered “at risk”.
I didn’t see any trace of [ImplicitThis] either, so that will make it hard to 
test (the Window interface given in the example is no longer using it).

 Is someone actually using dictionary constructors somewhere?  Are they 
 implemented by anyone?
Ah indeed no, and now I wonder why I added it in my list… (so as no specs seems 
to use them, I don’t think there are implementations around).

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

Re: PSA: publish WD of "WebIDL Level 1"

[Yves Lafon]

> On 07 Aug 2015, at 14:45, Arthur Barstow  wrote:
> 
> On 8/4/15 2:21 PM, Tab Atkins Jr. wrote:
>> On Thu, Jul 30, 2015 at 7:29 AM, Arthur Barstow  
>> wrote:
>>> Hi All,
>>> 
>>> This is heads-up re the intent to publish a Working Draft of "WebIDL Level
>>> 1" (on or around August 4) using Yves' document as the basis and a new
>>> "shortname" of "WebIDL-1":
>>> 
>>> 
>>> 
>>> There is an open question about what should happen with TR/WebIDL/ (which
>>> now is the 2012 Candidate Recommendation). One option is to serve it as
>>> WebIDL-1. Another option is to replace it with the latest version of
>>> Cameron's Editor's Draft. A third option is to make it some type of "landing
>>> page" the user can use to load the various versions. Feedback on these
>>> options is welcome and the default (if there are no non-resolvable issues)
>>> is to go with option #2 (Yves' preference).
>> The CSSWG always points the non-leveled url to the latest spec.
> 
> This is also what PLH recommended be done and that seems reasonable to me. 
> Thus:
> 
> TR/WebIDL/ -> TR/WebIDL-2/
> TR/WebIDL-1/
> TR/WebIDL-2/
> 
> The L2 version (by Cameron and Boris [L2]) has not been published as a TR and 
> if there no objections to proceeding as above, I will start working on making 
> this all happen.
> 
In fact, I would prefer to have the editors’ copy published as TR/WebIDL/, and 
let -1 -2 … -n be pointers to the stable version (aka, what is implemented, not 
what has to be implemented).

> -Thanks, AB
> 
> [L2] 

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

Re: PSA: publish WD of "WebIDL Level 1"

[Yves Lafon]

> On 31 Aug 2015, at 20:12, Ms2ger <ms2...@gmail.com> wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi Yves,
> 
> On 08/31/2015 03:28 PM, Yves Lafon wrote:
>> In fact, I would prefer to have the editors’ copy published as 
>> TR/WebIDL/, and let -1 -2 … -n be pointers to the stable version 
>> (aka, what is implemented, not what has to be implemented).
>> 
> 
> Who do you propose will construct such a "what is implemented"
> specification, and what useful work would you have them drop for it?

Well, we need tests, of course. There is a test suite that needs to be checked 
again,
and lots of other specs have tests that actually test parts of WebIDL. 
So apart from new functionalities that don’t have test yet (and may by mean of 
other specs testing those), most of the work is to gather existing tests, and I 
am ready to help on that. So I don’t ask anyone to stop doing their usual job, 
especially as it can also help here.
Of course people reviewing tests is always a nice feature, as you know.

> 
> Thanks
> Ms2ger
> -BEGIN PGP SIGNATURE-
> 
> iQEcBAEBAgAGBQJV5JkbAAoJEOXgvIL+s8n27aQH/jCaZRS6ONmC1aklZACK5Iep
> NV5VSxq1H2aHv6rdRiBNygeGzEiwENZUnIzv0r0ebQMCRCvhwXqbm+srV9FlFNdb
> dJ7c41cXNHIk4D1+18vYvK4AenqkHE5zozm4LqoZ8SL+YLRFYyIhpXOsV34R5DnP
> wjyLcEbcFgWmYK2TXTNphhTXEmebM89o4vmGkrKPdYqAwWaWNJz5L6hMZARH7lWq
> eYL0iwo9BQbIfR0gLIpuARvS2oOS0Y7/8gNkMuEQ4h9UHa+hcvsOL0JWI6Zz2vTM
> ZNO3nAE1h5In6DFXmK3ZkIlOpIGgsVsK7KmiIKlvZAOZ9NXui851uYA9j2YQQ3U=
> =ixCO
> -END PGP SIGNATURE-
> 

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

Re: PSA: publish WD of "WebIDL Level 1"

[Yves Lafon]

> On 01 Sep 2015, at 14:27, Ms2ger <ms2...@gmail.com> wrote:
> 
> Hi Yves,
> 
> On 09/01/2015 11:30 AM, Yves Lafon wrote:
>> On 31 Aug 2015, at 20:12, Ms2ger <ms2...@gmail.com> wrote:
>>> On 08/31/2015 03:28 PM, Yves Lafon wrote:
>>>> In fact, I would prefer to have the editors’ copy published as 
>>>> TR/WebIDL/, and let -1 -2 … -n be pointers to the stable version
>>>> (aka, what is implemented, not what has to be implemented).
>>>> 
>>> 
>>> Who do you propose will construct such a "what is implemented" 
>>> specification, and what useful work would you have them drop for
>>> it?
>>> 
>> 
>> Well, we need tests, of course. There is a test suite that needs to
>> be checked again, and lots of other specs have tests that actually
>> test parts of WebIDL. So apart from new functionalities that don’t
>> have test yet (and may by mean of other specs testing those), most of
>> the work is to gather existing tests, and I am ready to help on that.
>> So I don’t ask anyone to stop doing their usual job, especially as it
>> can also help here. Of course people reviewing tests is always a nice
>> feature, as you know.
>> 
> 
> I'm not sure I understand your point. Tests will need to be written and
> reviewed, whether "what is implemented" specifications are published or
> not. My question is specifically about the editing of the documents you
> propose to publish as -1 -2 … -n.
> 
As far as editing goes, the editors for level-1 are Travis and myself. No work 
is required from Boris and Cameron.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

Re: CfC: publish Candidate Recommendation of Web IDL Level 1; deadline December 9

[Yves Lafon]

> On 02 Dec 2015, at 16:11, Ms2ger  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi Art,
> 
> On 12/02/2015 02:23 PM, Arthur Barstow wrote:
>> Yves and Travis would like to publish a Candidate Recommendation
>> of WebIDL Level 1 and this is a Call for Consensus to do so. The
>> draft CR is:
>> 
>> 
>> 
>> If anyone has comments or concerns about this CfC, please reply by 
>> December 9 at the latest. Silence will be considered as agreeing
>> with the proposal and explicit responses are preferred. If no
>> non-resolvable blocking issues are raised, this CfC will be
>> considered as passing and we will proceed with a CR publication.
>> 
> 
> I'd like to see the difference between this proposed CR and the latest
> editor's draft.

(Sorry, some messages went to one ML only, reposting here the information about 
the difference).

This is the same as the previous Level 1 WD (well, same differences, as the 
proposed CR doc is with the latest modifications to the edcopy, like with Date 
removed.
So same as http://heycam.github.io/webidl/ with maplike, setlike, 
[ImplicitThis], [Unscopeable], RegExp, FrozenArray and LegacyArrayClass removed.
Thanks,

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

Re: Quick update on WebIDL "Level 1"

[Yves Lafon]

> On 10 Jul 2016, at 16:35, Marcos Caceres  wrote:
> 
> On July 9, 2016 at 6:24:56 AM, Domenic Denicola (d...@domenic.me) wrote:
>> From: Travis Leithead [mailto:travis.leith...@microsoft.com]
>> 
>>> The purpose of the “Level 1” document is to serve as a stable reference for 
>>> W3C specs that
>> link to WebIDL. It contains a subset of the WebIDL syntax that is considered 
>> stable (as
>> verified by interoperable tests). Implementations should not use the Level 1 
>> document
>> as a guide, but instead track changes to the editors draft. We expect to 
>> follow-up Level
>> 1 with a Level 2 as additional editor’s draft syntax and behavior 
>> stabilizes, are implemented
>> as part of other specs, and shown to be interoperable.
>> 
>> Why is it acceptable for specs to reference a version of Web IDL that nobody 
>> should implement?
> 
> This is a totally valid question, but we've had this debate 1001
> times. Perhaps a better question is: how can we get patent protection
> (making this subset of WebIDL royalty free for society), but without
> harming the ecosystem by confusing implementers and developers by
> publishing on the "/TRash" space (as most of us now unfortunately
> referring to it).
> 
> We need a way to clearly indicate that, for a subset of documents,
> RECs on TR represent a royalty free set of ideas (as kindly and
> honorably granted by the W3C Membership) - and should only be referred
> to by patent lawyers and government officials. That it's for those
> groups should be stated and promoted proudly, not disparagingly. And,
> that implementers should be looking at the living document instead.
> The value of TR need not be diminished - in fact: it should be
> correctly used to published the documents that enshrine the royalty
> free status of particular specifications.

The goal of publishing this as a REC is not to have a final document nor to 
please only
the lawyers. The goal is to provide a document that contains the parts of the 
WebIDL
syntax that are implemented, and the associated implemented ES-binding, as a 
guide
for spec authors that are not following the main WebIDL spec evolutions (as not 
everybody 
has your knowledge of what is or is not usable in WebIDL).

The -1 spec explicitly states that people wanting to implement WebIDL are 
invited to read
the main WebIDL specification (that, ideally, should be automatically published 
as /TR/WebIDL ) because yes
WebIDL-1 is _not_ the WebIDL specification, just a frozen snapshot of what was 
implemented as the 
time of publication, not more than that, and bound to be replaced by a 
subsequent level later on.

> Perhaps we need a new space just for documents that represent and
> agree to set of royalty free ideas? (i..e, if it's a REC, it does into
> this new space - and gets clearly marked for the appropriate target
> audience, which is not implementers or developers - but patent lawyers
> and government officials)...
> 
> I think we've also had this debate 10001 times too... but we need to
> do something folks, as the division between the forks and the reality
> of how web specs are developed is hurting everyone :(
> 
> Kind regards,
> Marcos
> 

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves