groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keegan Witt <keeganw...@gmail.com>
Subject Re: UTF16 BOM in new PrintWriter() vs withPrintWriter()
Date Sun, 05 Jul 2015 22:31:03 GMT
I'm starting work on this.  Just to be clear (since we didn't really
discuss this): Do we want to make only newPrintWriter() not default to
writing a BOM?  Or also write() and append() methods not default to writing
a BOM?  I was thinking we would change all 3 so their behavior is
consistent.  What do you think?

On Thu, Jun 11, 2015 at 9:19 AM, Keegan Witt <keeganwitt@gmail.com> wrote:

> I created GROOVY-7465 <https://issues.apache.org/jira/browse/GROOVY-7465> to
> track this.
>
> -Keegan
>
> On Tue, Jun 9, 2015 at 4:04 PM, Keegan Witt <keeganwitt@gmail.com> wrote:
>
>> I'd be OK with that.  I think having false by default is the *Right
>> Thing™*, but true has a certain allure since it'd reduce the risk of
>> breaking existing code (hard to guess how likely breakage is).  Tough
>> choice.  Even if we defaulted to true, it's an improvement over current
>> state since it gives users the flexibility, and calling it out as a
>> parameter might elicit more thought and attention than just a JavaDoc
>> comment.
>>
>> On Tue, Jun 9, 2015 at 3:50 PM, Guillaume Laforge <glaforge@gmail.com>
>> wrote:
>>
>>> So let's say, perhaps, we don't generate a BOM, unless asked
>>> specifically... but not with new methods, but with new parameters to such
>>> methods. In addition to specifying a charset, we could also pass a boolean
>>> saying we want a BOM to be generated (false by default, needs to be
>>> specified as true if BOM wanted) ?
>>>
>>> 2015-06-09 21:47 GMT+02:00 Keegan Witt <keeganwitt@gmail.com>:
>>>
>>>> I get that -- and I wish JDK did the same.  But what bothers me most
>>>> about the current state is that sometimes it's transparent, sometimes it's
>>>> not -- depending on how it was invoked.  And while we could fix the new
>>>> instance usage too with metaClass, that could lead to weird inconsistencies
>>>> when Groovy is invoked from Java.
>>>>
>>>> I really think most users would not expect these two usages to behave
>>>> differently.  I think most would expect the difference to be stylistic
>>>> only.  So as much as it pains me to say this, I think it's better not to
>>>> violate the principle of least surprise, and remain consistent across all
>>>> styles of invocation with Java's poor life choices.
>>>>
>>>> But maybe the friendlier APIs can be moved into new methods, such as
>>>> newBomAwareWriter() / WithBomAwareWriter{}  What do you think?  If we
>>>> did that, I guess it'd be consistent to do the same for the readers as well.
>>>>
>>>> -Keegan
>>>>
>>>> On Tue, Jun 9, 2015 at 3:22 PM, Guillaume Laforge <glaforge@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> 2015-06-09 18:57 GMT+02:00 Keegan Witt <keeganwitt@gmail.com>:
>>>>>
>>>>>> I created PR 37 <https://github.com/apache/incubator-groovy/pull/37>
>>>>>> to correct the JavaDoc I mentioned (as well as to document the existing
>>>>>> behavior for the non-NIO methods).
>>>>>>
>>>>>> Java doesn't eat the BOM, but this is a problem Java folks are used
>>>>>> to dealing with, and why things like Apache Common-IO's
>>>>>> BOMInputStream
>>>>>> <https://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/input/BOMInputStream.html>
>>>>>> exist.
>>>>>>
>>>>>
>>>>> That's also why I made Groovy eat the BOM too, so that it's
>>>>> transparent to our users :-)
>>>>> But that was a long time ago since I worked on those parts of the
>>>>> codebase, and it's been refactored quite a bit (by Jim for example).
>>>>>
>>>>>
>>>>>>
>>>>>> -Keegan
>>>>>>
>>>>>> On Tue, Jun 9, 2015 at 11:33 AM, Guillaume Laforge <
>>>>>> glaforge@gmail.com> wrote:
>>>>>>
>>>>>>> So now, how to decide what's best? :-)
>>>>>>>
>>>>>>> Is a Java reader happy with the BOM? and eats it transparently?
(I
>>>>>>> think in the past that wasn't the case but I may be wrong)
>>>>>>>
>>>>>>> 2015-06-09 17:21 GMT+02:00 Keegan Witt <keeganwitt@gmail.com>:
>>>>>>>
>>>>>>>> That's an excellent point, Paolo.  NioGroovyMethods.newWriter
>>>>>>>> claims (in the JavaDoc) it will write the BOM if needed,
but it doesn't
>>>>>>>> because it uses Java's implementation rather than with Groovy's
>>>>>>>> writeUTF16BomIfRequired.  None of the methods in NioGroovyMethods
>>>>>>>>  use writeUTF16BomIfRequired.
>>>>>>>>
>>>>>>>> Whichever we decide, we should be consistent.
>>>>>>>>
>>>>>>>> -Keegan
>>>>>>>>
>>>>>>>> On Tue, Jun 9, 2015 at 11:08 AM, Paolo Di Tommaso <
>>>>>>>> paolo.ditommaso@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I'm wondering if NioGroovyMethods that implement the
write methods
>>>>>>>>> for Path should do the same.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Paolo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jun 9, 2015 at 4:02 PM, Keegan Witt <keeganwitt@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Cool.  I'll wait for PR 36 to be merged first, because
I also was
>>>>>>>>>> thinking the Javadoc would be changed from
>>>>>>>>>>     is "UTF-16BE" or "UTF-16LE"
>>>>>>>>>> to
>>>>>>>>>>     is "UTF-16BE" or "UTF-16LE" (or an equivalent
alias)
>>>>>>>>>>
>>>>>>>>>> -Keegan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Jun 9, 2015 at 9:08 AM, Guillaume Laforge
<
>>>>>>>>>> glaforge@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2015-06-09 15:04 GMT+02:00 Keegan Witt <keeganwitt@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> Created GROOVY-7461
>>>>>>>>>>>> <https://issues.apache.org/jira/browse/GROOVY-7461>
and PR 36
>>>>>>>>>>>> <https://github.com/apache/incubator-groovy/pull/36>.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Cool!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> How would you feel about a PR to copy the
Javadoc comment
>>>>>>>>>>>> mentioning the UTF-16 BOM on File.newWriter
to all the other
>>>>>>>>>>>> methods that use writeUTF16BomIfRequired
(at least until we
>>>>>>>>>>>> decide we're going to change the current
behavior)?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Right, worth it!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -Keegan
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jun 9, 2015 at 8:17 AM, Guillaume
Laforge <
>>>>>>>>>>>> glaforge@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Good point!
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2015-06-09 14:11 GMT+02:00 Keegan Witt
<keeganwitt@gmail.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> That's only available in Java 7.
 Isn't Groovy still
>>>>>>>>>>>>>> targeting 1.6 for the non-indy version?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Keegan
>>>>>>>>>>>>>> On Jun 9, 2015 7:56 AM, "Guillaume
Laforge" <
>>>>>>>>>>>>>> glaforge@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Well spotted!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You could also compare with the
StandardCharset, instead of
>>>>>>>>>>>>>>> going through the name comparison:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://docs.oracle.com/javase/7/docs/api/java/nio/charset/StandardCharsets.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2015-06-09 13:49 GMT+02:00 Keegan
Witt <keeganwitt@gmail.com
>>>>>>>>>>>>>>> >:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, it's a Groovy bug.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> private static void writeUTF16BomIfRequired(final
String charset, final OutputStream stream) throws IOException {
>>>>>>>>>>>>>>>>     if ("UTF-16BE".equals(charset))
{
>>>>>>>>>>>>>>>>         writeUtf16Bom(stream,
true);
>>>>>>>>>>>>>>>>     } else if ("UTF-16LE".equals(charset))
{
>>>>>>>>>>>>>>>>         writeUtf16Bom(stream,
false);
>>>>>>>>>>>>>>>>     }
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> should be
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> private static void writeUTF16BomIfRequired(final
String charset, final OutputStream stream) throws IOException {
>>>>>>>>>>>>>>>>     if ("UTF-16BE".equals(Charset.forName(charset).name()))
{
>>>>>>>>>>>>>>>>         writeUtf16Bom(stream,
true);
>>>>>>>>>>>>>>>>     } else if ("UTF-16LE".equals(Charset.forName(charset).name()))
{
>>>>>>>>>>>>>>>>         writeUtf16Bom(stream,
false);
>>>>>>>>>>>>>>>>     }
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> in org.codehaus.groovy.runtime.ResourceGroovyMethods.
>>>>>>>>>>>>>>>> We'll probably want to fix
that regardless of what we decide on the
>>>>>>>>>>>>>>>> *withPrintWriter* question.
 I'll open a Jira and a PR.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Keegan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Jun 9, 2015 at 3:21
AM, Guillaume Laforge <
>>>>>>>>>>>>>>>> glaforge@gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> From Groovy's point of
view (ie. when you're coding in
>>>>>>>>>>>>>>>>> Groovy), the BOM is automatically
discarded when you use one of our reader
>>>>>>>>>>>>>>>>> methods (withReader,
etc), so it's transparent whether the BOM is here or
>>>>>>>>>>>>>>>>> not.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I tend to think that
having the BOM always is a good thing
>>>>>>>>>>>>>>>>> (I even thought that
was mandatory), but Groovy should guess the endianness
>>>>>>>>>>>>>>>>> regardless anyway.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Happy to hear what others
think too about all this though.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Guillaume
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2015-06-08 23:20 GMT+02:00
Keegan Witt <
>>>>>>>>>>>>>>>>> keeganwitt@gmail.com>:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The code as-is today
writes the BOM regardless of
>>>>>>>>>>>>>>>>>> platform.  I just
tested in Linux with the same results.  I think there are
>>>>>>>>>>>>>>>>>> 2 parts to the question
of "what's the correct behavior?"
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1.  Should the BOM
be written at all, particularly when
>>>>>>>>>>>>>>>>>> the platform is Windows?
>>>>>>>>>>>>>>>>>> 2.  Should the behavior
of *withPrintWriter* differ
>>>>>>>>>>>>>>>>>> (even if the difference
is to be smarter) from the behavior of *new
>>>>>>>>>>>>>>>>>> PrintWriter*?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *Discussion*
>>>>>>>>>>>>>>>>>> 1.  Strictly speaking,
yes.  Because RFC 2781
>>>>>>>>>>>>>>>>>> <http://tools.ietf.org/html/rfc2781>
states in section
>>>>>>>>>>>>>>>>>> 4.3 to assume big
endian if there is no BOM.  However, in practice, many
>>>>>>>>>>>>>>>>>> applications disregard
the RFC and assume little-endian because that's what Windows
>>>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>>>> <https://msdn.microsoft.com/en-us/library/windows/desktop/dd374101%28v=vs.85%29.aspx>.
>>>>>>>>>>>>>>>>>> Because of this,
the behavior could be changed so that when writing
>>>>>>>>>>>>>>>>>> UTF-16LE on Windows,
it doesn't write the BOM.  But in my opinion, it's
>>>>>>>>>>>>>>>>>> best practice to
always write a BOM when working with UTF-16, and Java
>>>>>>>>>>>>>>>>>> should have done
this in their implementation of their PrintWriter.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2.  This is a tough
one.  Arguably, *withPrintWriter* is
>>>>>>>>>>>>>>>>>> doing the smarter,
more correct behavior, but the typical user would assume
>>>>>>>>>>>>>>>>>> this is just a shorthand
convenience for newing up a PrintWriter (I
>>>>>>>>>>>>>>>>>> certainly did). 
So the question is, is it better to just document this
>>>>>>>>>>>>>>>>>> difference in the
GroovyDoc?  Or to change the behavior to be closer to
>>>>>>>>>>>>>>>>>> Java?  And if the
latter, what breakages would that cause within Groovy
>>>>>>>>>>>>>>>>>> itself?  Making that
change could break folks in production, because they
>>>>>>>>>>>>>>>>>> could rely on that
BOM being there, in cases for example where the file is
>>>>>>>>>>>>>>>>>> created on Windows,
but then processed on Linux or when working with a
>>>>>>>>>>>>>>>>>> third party library
that is more picky about the presence of a BOM.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -Keegan
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, Jun 8, 2015
at 4:32 PM, Guillaume Laforge <
>>>>>>>>>>>>>>>>>> glaforge@gmail.com>
wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Now... is it
what should be done or not is the good
>>>>>>>>>>>>>>>>>>> question to ask
:-)
>>>>>>>>>>>>>>>>>>> Does Windows
manages to open UTF-16 files without BOMs?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2015-06-08 22:17
GMT+02:00 Keegan Witt <
>>>>>>>>>>>>>>>>>>> keeganwitt@gmail.com>:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I forgot
to mention that.  Yes, I ran the test
>>>>>>>>>>>>>>>>>>>> mentioned
in Windows.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Mon, Jun
8, 2015 at 3:54 PM, Guillaume Laforge <
>>>>>>>>>>>>>>>>>>>> glaforge@gmail.com>
wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> That's
a good question.
>>>>>>>>>>>>>>>>>>>>> I guess
this is happening on Windows? (I haven't tried
>>>>>>>>>>>>>>>>>>>>> here,
since I'm on OS X)
>>>>>>>>>>>>>>>>>>>>> I think
BOMs were mandatory in text files on Windows.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2015-06-08
17:53 GMT+02:00 Keegan Witt <
>>>>>>>>>>>>>>>>>>>>> keeganwitt@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I've
always taken a perverse pleasure in character
>>>>>>>>>>>>>>>>>>>>>> encoding
problems.  I was intrigued by this SO
>>>>>>>>>>>>>>>>>>>>>> question
>>>>>>>>>>>>>>>>>>>>>> <http://stackoverflow.com/questions/30538461/why-groovy-file-write-with-utf-16le-produce-bom-char>
on
>>>>>>>>>>>>>>>>>>>>>> UTF
16 BOMs in Java vs Groovy.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It
appears using withPrintWriter(charset) produces a
>>>>>>>>>>>>>>>>>>>>>> BOM
whereas new PrintWriter(file, charset) does
>>>>>>>>>>>>>>>>>>>>>> not.
 As demonstrated here:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> File
file = new File("tmp.txt")try {
>>>>>>>>>>>>>>>>>>>>>> 
   String text = " "
>>>>>>>>>>>>>>>>>>>>>> 
   String charset = "UTF-16LE"
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 
   file.withPrintWriter(charset) { it << text }
>>>>>>>>>>>>>>>>>>>>>> 
   println "withPrintWriter"
>>>>>>>>>>>>>>>>>>>>>> 
   file.getBytes().each { System.out.format("%02x ", it) }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 
   PrintWriter w = new PrintWriter(file, charset)
>>>>>>>>>>>>>>>>>>>>>> 
   w.print(text)
>>>>>>>>>>>>>>>>>>>>>> 
   w.close()
>>>>>>>>>>>>>>>>>>>>>> 
   println "\n\nnew PrintWriter"
>>>>>>>>>>>>>>>>>>>>>> 
   file.getBytes().each { System.out.format("%02x ", it) }} finally {
>>>>>>>>>>>>>>>>>>>>>> 
   file.delete()}
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Outputs
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> withPrintWriter
>>>>>>>>>>>>>>>>>>>>>> ff
fe 20 00
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> new
PrintWriter
>>>>>>>>>>>>>>>>>>>>>> 20
00
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Is
this difference in behavior intentional?  It seems
>>>>>>>>>>>>>>>>>>>>>> kinda
odd to me.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> -Keegan
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Guillaume
Laforge
>>>>>>>>>>>>>>>>>>>>> Groovy
Project Manager
>>>>>>>>>>>>>>>>>>>>> Product
Ninja & Advocate at Restlet
>>>>>>>>>>>>>>>>>>>>> <http://restlet.com>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Blog:
http://glaforge.appspot.com/
>>>>>>>>>>>>>>>>>>>>> Social:
@glaforge <http://twitter.com/glaforge> /
>>>>>>>>>>>>>>>>>>>>> Google+
>>>>>>>>>>>>>>>>>>>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Guillaume Laforge
>>>>>>>>>>>>>>>>>>> Groovy Project
Manager
>>>>>>>>>>>>>>>>>>> Product Ninja
& Advocate at Restlet <http://restlet.com>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Blog: http://glaforge.appspot.com/
>>>>>>>>>>>>>>>>>>> Social: @glaforge
<http://twitter.com/glaforge> /
>>>>>>>>>>>>>>>>>>> Google+
>>>>>>>>>>>>>>>>>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Guillaume Laforge
>>>>>>>>>>>>>>>>> Groovy Project Manager
>>>>>>>>>>>>>>>>> Product Ninja & Advocate
at Restlet <http://restlet.com>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Blog: http://glaforge.appspot.com/
>>>>>>>>>>>>>>>>> Social: @glaforge <http://twitter.com/glaforge>
/ Google+
>>>>>>>>>>>>>>>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Guillaume Laforge
>>>>>>>>>>>>>>> Groovy Project Manager
>>>>>>>>>>>>>>> Product Ninja & Advocate
at Restlet <http://restlet.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Blog: http://glaforge.appspot.com/
>>>>>>>>>>>>>>> Social: @glaforge <http://twitter.com/glaforge>
/ Google+
>>>>>>>>>>>>>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Guillaume Laforge
>>>>>>>>>>>>> Groovy Project Manager
>>>>>>>>>>>>> Product Ninja & Advocate at Restlet
<http://restlet.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Blog: http://glaforge.appspot.com/
>>>>>>>>>>>>> Social: @glaforge <http://twitter.com/glaforge>
/ Google+
>>>>>>>>>>>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Guillaume Laforge
>>>>>>>>>>> Groovy Project Manager
>>>>>>>>>>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>>>>>>>>>>
>>>>>>>>>>> Blog: http://glaforge.appspot.com/
>>>>>>>>>>> Social: @glaforge <http://twitter.com/glaforge>
/ Google+
>>>>>>>>>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Guillaume Laforge
>>>>>>> Groovy Project Manager
>>>>>>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>>>>>>
>>>>>>> Blog: http://glaforge.appspot.com/
>>>>>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>>>>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Guillaume Laforge
>>>>> Groovy Project Manager
>>>>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>>>>
>>>>> Blog: http://glaforge.appspot.com/
>>>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Guillaume Laforge
>>> Groovy Project Manager
>>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>>
>>> Blog: http://glaforge.appspot.com/
>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>
>>
>>
>

Mime
View raw message