Re: Updated idlharness.js

On Thu, Jan 24, 2013 at 12:25 PM, François REMY <
francois.remy.dev@outlook.com> wrote:

> Both points are interesting (contacting public-webapps & keeping a code in
> sync). Let’s address them separately.
>
> *(1) Report our work on WebIDL2.js to public-webapps*
>
> I’m not following that mailing list at the moment, but I’ll do so very
> soon (like: tonight). I’m OK to take on me to respond to Robin’s message to
> explain our work (even if we didn’t use the parser as of now because we
> focused our work on type conversion, we plan to do so very soon).
>
>
FWIW, I did send him an email yesterday letting him know about the project
very vaguely (pointed him at our group, told him we intended to use his
parser and pointed him at the github) - but we should follow up with the
larger intent and some details.


> Because we already reported two valid bugs for the WebIDL specification
> (NaN/infinity to “any” conversion & octet conversion), our work may be
> interesting for the webapps guys and their review of the version 2 of the
> spec.
>
>
Agree.


> *(2) Keeping a draft in sync with generated code*
>
> This is a very interesting issue. Indeed, the generated stub will likely
> be filled in by the developer and as soon as the draft changes, a ‘merge’
> strategy may be needed to keep the prolyfill up to date.
>
> I propose for now that we encourage to use a text-difference-based merging
> tool (if developpers don’t touch the structure of the file too much, they
> should be able to spot the differences very quickly and merge efficiently
> the changes in their existing code).
>
> In the long run, we may even provide a ‘reverse’ parser that would copy
> implementation code from one version to the other and warn for the places
> that may need an update.
>
This is actually exactly what I am suggesting I think... Marcos and I had
an etherpad with some notes/discussion... Not sure what happened to it, I
can't seem to find it ATM.  Essentially though, it should be easy enough to
just provide some DOM info (class or something) indicating that something
is WEB-IDL, drafts should probably already have that defined... We can
parse and generate stubs out of it.  The stubs could contain
meta-information (or generate a seperate meta-file) which would allow
reversing the process to keep the draft up to date..



>
>
>
>
>  *De :* Brian Kardell
> *Envoyé :* 24 janvier 2013 18:10
> *À :* Marcos Caceres
> *Cc :* Clint Hill, François REMY, public-nextweb@w3.org
> *Objet :* Re: Updated idlharness.js
>
> On Thu, Jan 24, 2013 at 11:37 AM, Marcos Caceres <w3c@marcosc.com> wrote:
>
>> I think it would be good to announce and see if we can get some more
>> people involved in our group. It might also serve as a barometer to check
>> people's interest in what we are trying to achieve.
>>
>> --
>> Marcos Caceres
>>
>>
> Does anyone else feel that it might be good to lay out a longer vision for
> this in terms of how we might provide an ability to keep a draft's WebIDL
> in sync from source or something?
>



-- 
Brian Kardell :: @briankardell :: hitchjs.com