Trying to wrap up 7465 this week. Got one more question: What do you think of making *getText* and *getBytes* take an arg of whether to strip the BOM (if found)?
-Keegan On Tue, Jul 7, 2015 at 2:44 PM, Guillaume Laforge <glafo...@gmail.com> wrote: > Agreed on consistency too. > > 2015-07-07 20:38 GMT+02:00 Pascal Schumacher <pascalschumac...@gmx.net>: > >> I agree, the behavior should be consistent. >> >> Am 06.07.2015 um 00:31 schrieb Keegan Witt: >> >> 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 <keeganw...@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 < <keeganw...@gmail.com> >>> keeganw...@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 <glafo...@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 < <keeganw...@gmail.com> >>>>> keeganw...@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 < >>>>>> <glafo...@gmail.com>glafo...@gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> 2015-06-09 18:57 GMT+02:00 Keegan Witt < <keeganw...@gmail.com> >>>>>>> keeganw...@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 < >>>>>>>> <glafo...@gmail.com>glafo...@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 < <keeganw...@gmail.com> >>>>>>>>> keeganw...@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.ditomm...@gmail.com>paolo.ditomm...@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 < >>>>>>>>>>> <keeganw...@gmail.com>keeganw...@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 < >>>>>>>>>>>> <glafo...@gmail.com>glafo...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2015-06-09 15:04 GMT+02:00 Keegan Witt < >>>>>>>>>>>>> <keeganw...@gmail.com>keeganw...@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 < >>>>>>>>>>>>>> <glafo...@gmail.com>glafo...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Good point! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2015-06-09 14:11 GMT+02:00 Keegan Witt < >>>>>>>>>>>>>>> <keeganw...@gmail.com>keeganw...@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" < >>>>>>>>>>>>>>>> <glafo...@gmail.com>glafo...@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> >>>>>>>>>>>>>>>>> http://docs.oracle.com/javase/7/docs/api/java/nio/charset/StandardCharsets.html >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2015-06-09 13:49 GMT+02:00 Keegan Witt < >>>>>>>>>>>>>>>>> <keeganw...@gmail.com>keeganw...@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 < >>>>>>>>>>>>>>>>>> <glafo...@gmail.com>glafo...@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 < >>>>>>>>>>>>>>>>>>> <keeganw...@gmail.com>keeganw...@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 < >>>>>>>>>>>>>>>>>>>> <glafo...@gmail.com>glafo...@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 < >>>>>>>>>>>>>>>>>>>>> <keeganw...@gmail.com>keeganw...@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 < >>>>>>>>>>>>>>>>>>>>>> <glafo...@gmail.com>glafo...@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 < >>>>>>>>>>>>>>>>>>>>>>> <keeganw...@gmail.com>keeganw...@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/> >>>>>>>>>>>>>>>>>>>>>>> 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/> >>>>>>>>>>>>>>>>>>>>> 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/> >>>>>>>>>>>>>>>>>>> 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/> >>>>>>>>>>>>>>>>> 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/> >>>>>>>>>>>>>>> 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/> >>>>>>>>>>>>> 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/>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/>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/>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> >
