You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Nick Dimiduk <nd...@gmail.com> on 2013/08/02 03:30:06 UTC
Re: Data types stage 1 is ready for reivew
Finally-for-real-this-time patches posted. I'll take your +1's any time now
;)
Thanks,
Nick
On Wed, Jul 24, 2013 at 11:27 AM, Nick Dimiduk <nd...@gmail.com> wrote:
> Hi everyone,
>
> As of yesterday, I've posted "final" patched on both HBASE-8201<https://issues.apache.org/jira/browse/HBASE-8201>and
> HBASE-8693 <https://issues.apache.org/jira/browse/HBASE-8693>. The former
> specifies on-disk format and the latter is the user-facing API. If you've
> already left me a review, thank you; please have another look at these
> patches. If you have an opinion here and haven't voiced it, we're
> approaching the "forever hold your peace" part of the ceremony.
>
> Thanks,
> Nick
>
>
> On Wed, Jul 17, 2013 at 9:33 AM, Nick Dimiduk <nd...@gmail.com> wrote:
>
>> Thanks for having a look. If you don't mind terribly, I responded to your
>> comments on JIRA [0].
>>
>> Thanks,
>> Nick
>>
>> [0]: https://issues.apache.org/jira/browse/HBASE-8693#comment-13711250
>>
>>
>> On Wed, Jul 17, 2013 at 1:42 AM, Matteo Bertozzi <theo.bertozzi@gmail.com
>> > wrote:
>>
>>> I was looking at the HBASE-8693 patch, and looks good to me for the
>>> primitive types.
>>> but I can't see how do you plan to evolve stuff like the struct.
>>> By "evolve" I mean add/remove fields, or just query it with a subset of
>>> fields.
>>> the fields don't have an id, and on read you must specify all of them in
>>> the same order as you've used for write.
>>> (but maybe is just an immutable/fixed list of fields, and I'm ok with
>>> just
>>> adding that info to the comment on top of the class)
>>>
>>>
>>> Matteo
>>>
>>>
>>>
>>> On Wed, Jul 17, 2013 at 12:39 AM, Nick Dimiduk <nd...@gmail.com>
>>> wrote:
>>>
>>> > New patch posted. What do you think about the new isSkippable() and the
>>> > associated limitation in Struct?
>>> >
>>> > I also posted some "dogfeed" per Enis's suggestion.
>>> >
>>> > -n
>>> >
>>> > On Fri, Jul 12, 2013 at 1:38 PM, Stack <st...@duboce.net> wrote:
>>> >
>>> > > On Fri, Jul 12, 2013 at 1:10 PM, Enis Söztutar <en...@apache.org>
>>> wrote:
>>> > >
>>> > > > Did some chatting with Nick today.
>>> > > >
>>> > > > I think it is really important to get this right, and for that we
>>> would
>>> > > > definitely need more eyes towards it. The current patch set is in a
>>> > good
>>> > > > state to bolster the discussion.
>>> > > >
>>> > > >
>>> > >
>>> > > I'll do another pass (Kicking others to give it a looksee too).
>>> > > St.Ack
>>> > >
>>> >
>>>
>>
>>
>
Re: Data types stage 1 is ready for reivew
Posted by Nick Dimiduk <nd...@gmail.com>.
An extra week of reviews and comments and updates is behind us. Here's a
summary of the high-level changes.
- Matt's ByteRange class has been refactored into an interface. That
interface is extended to PositionedByteRange that provides the API goodness
many of you desired. HBASE-9091.
- The encoding OrderedBytes methods all operate over PositionedByteRange
now. Implementations are largely unchanged. Docstrings have been tightened
up a fair bit. HBASE-8201.
- The data type API also operates over PositionedByteRange. For all the
data type implementations built on o.a.h.h.u.Bytes, the name "Legacy" is
replaced with "Raw." The FixedLengthWrapper class now provides a method to
inspect its length. HBASE-8693.
- All remaining issues are outside of the critical scope of on-disk
formats and user-level APIs, and are deferred to follow-up JIRAs.
Thanks,
Nick
On Sat, Aug 3, 2013 at 11:24 AM, Jean-Marc Spaggiari <
jean-marc@spaggiari.org> wrote:
> This is my preferred approach. Many users don't want to have any types on
> the data because they might already have their own format, or just because
> they don't need it.
>
> So we should not enforce clients to use it.
>
> JM
>
> 2013/8/3 Nick Dimiduk <nd...@gmail.com>
>
> > On Sat, Aug 3, 2013 at 10:33 AM, Michael Segel <
> msegel_hadoop@hotmail.com
> > >wrote:
> >
> > > How do you plan on enforcing data types within the engine?
> > >
> >
> > Data types, at this point, are a client-side feature, not enforced by the
> > engine in anyway.
> >
> > On Aug 1, 2013, at 10:57 PM, Matt Corgan <mc...@hotpads.com> wrote:
> > >
> > > > Looks great to me. Without the strict dependencies on hadoop or
> hbase
> > > > it'll be easy to pull into its own standalone module or new project
> if
> > > > there's demand.
> > > >
> > > >
> > > > On Thu, Aug 1, 2013 at 6:30 PM, Nick Dimiduk <nd...@gmail.com>
> > wrote:
> > > >
> > > >> Finally-for-real-this-time patches posted. I'll take your +1's any
> > time
> > > now
> > > >> ;)
> > > >>
> > > >> Thanks,
> > > >> Nick
> > > >>
> > > >> On Wed, Jul 24, 2013 at 11:27 AM, Nick Dimiduk <nd...@gmail.com>
> > > wrote:
> > > >>
> > > >>> Hi everyone,
> > > >>>
> > > >>> As of yesterday, I've posted "final" patched on both HBASE-8201<
> > > >> https://issues.apache.org/jira/browse/HBASE-8201>and
> > > >>> HBASE-8693 <https://issues.apache.org/jira/browse/HBASE-8693>. The
> > > >> former
> > > >>> specifies on-disk format and the latter is the user-facing API. If
> > > you've
> > > >>> already left me a review, thank you; please have another look at
> > these
> > > >>> patches. If you have an opinion here and haven't voiced it, we're
> > > >>> approaching the "forever hold your peace" part of the ceremony.
> > > >>>
> > > >>> Thanks,
> > > >>> Nick
> > > >>>
> > > >>>
> > > >>> On Wed, Jul 17, 2013 at 9:33 AM, Nick Dimiduk <nd...@gmail.com>
> > > >> wrote:
> > > >>>
> > > >>>> Thanks for having a look. If you don't mind terribly, I responded
> to
> > > >> your
> > > >>>> comments on JIRA [0].
> > > >>>>
> > > >>>> Thanks,
> > > >>>> Nick
> > > >>>>
> > > >>>> [0]:
> > > https://issues.apache.org/jira/browse/HBASE-8693#comment-13711250
> > > >>>>
> > > >>>>
> > > >>>> On Wed, Jul 17, 2013 at 1:42 AM, Matteo Bertozzi <
> > > >> theo.bertozzi@gmail.com
> > > >>>>> wrote:
> > > >>>>
> > > >>>>> I was looking at the HBASE-8693 patch, and looks good to me for
> the
> > > >>>>> primitive types.
> > > >>>>> but I can't see how do you plan to evolve stuff like the struct.
> > > >>>>> By "evolve" I mean add/remove fields, or just query it with a
> > subset
> > > of
> > > >>>>> fields.
> > > >>>>> the fields don't have an id, and on read you must specify all of
> > them
> > > >> in
> > > >>>>> the same order as you've used for write.
> > > >>>>> (but maybe is just an immutable/fixed list of fields, and I'm ok
> > with
> > > >>>>> just
> > > >>>>> adding that info to the comment on top of the class)
> > > >>>>>
> > > >>>>>
> > > >>>>> Matteo
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> On Wed, Jul 17, 2013 at 12:39 AM, Nick Dimiduk <
> ndimiduk@gmail.com
> > >
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> New patch posted. What do you think about the new isSkippable()
> > and
> > > >> the
> > > >>>>>> associated limitation in Struct?
> > > >>>>>>
> > > >>>>>> I also posted some "dogfeed" per Enis's suggestion.
> > > >>>>>>
> > > >>>>>> -n
> > > >>>>>>
> > > >>>>>> On Fri, Jul 12, 2013 at 1:38 PM, Stack <st...@duboce.net>
> wrote:
> > > >>>>>>
> > > >>>>>>> On Fri, Jul 12, 2013 at 1:10 PM, Enis Söztutar <
> enis@apache.org>
> > > >>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> Did some chatting with Nick today.
> > > >>>>>>>>
> > > >>>>>>>> I think it is really important to get this right, and for that
> > we
> > > >>>>> would
> > > >>>>>>>> definitely need more eyes towards it. The current patch set is
> > > >> in a
> > > >>>>>> good
> > > >>>>>>>> state to bolster the discussion.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>> I'll do another pass (Kicking others to give it a looksee too).
> > > >>>>>>> St.Ack
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>
Re: Data types stage 1 is ready for reivew
Posted by Jean-Marc Spaggiari <je...@spaggiari.org>.
This is my preferred approach. Many users don't want to have any types on
the data because they might already have their own format, or just because
they don't need it.
So we should not enforce clients to use it.
JM
2013/8/3 Nick Dimiduk <nd...@gmail.com>
> On Sat, Aug 3, 2013 at 10:33 AM, Michael Segel <msegel_hadoop@hotmail.com
> >wrote:
>
> > How do you plan on enforcing data types within the engine?
> >
>
> Data types, at this point, are a client-side feature, not enforced by the
> engine in anyway.
>
> On Aug 1, 2013, at 10:57 PM, Matt Corgan <mc...@hotpads.com> wrote:
> >
> > > Looks great to me. Without the strict dependencies on hadoop or hbase
> > > it'll be easy to pull into its own standalone module or new project if
> > > there's demand.
> > >
> > >
> > > On Thu, Aug 1, 2013 at 6:30 PM, Nick Dimiduk <nd...@gmail.com>
> wrote:
> > >
> > >> Finally-for-real-this-time patches posted. I'll take your +1's any
> time
> > now
> > >> ;)
> > >>
> > >> Thanks,
> > >> Nick
> > >>
> > >> On Wed, Jul 24, 2013 at 11:27 AM, Nick Dimiduk <nd...@gmail.com>
> > wrote:
> > >>
> > >>> Hi everyone,
> > >>>
> > >>> As of yesterday, I've posted "final" patched on both HBASE-8201<
> > >> https://issues.apache.org/jira/browse/HBASE-8201>and
> > >>> HBASE-8693 <https://issues.apache.org/jira/browse/HBASE-8693>. The
> > >> former
> > >>> specifies on-disk format and the latter is the user-facing API. If
> > you've
> > >>> already left me a review, thank you; please have another look at
> these
> > >>> patches. If you have an opinion here and haven't voiced it, we're
> > >>> approaching the "forever hold your peace" part of the ceremony.
> > >>>
> > >>> Thanks,
> > >>> Nick
> > >>>
> > >>>
> > >>> On Wed, Jul 17, 2013 at 9:33 AM, Nick Dimiduk <nd...@gmail.com>
> > >> wrote:
> > >>>
> > >>>> Thanks for having a look. If you don't mind terribly, I responded to
> > >> your
> > >>>> comments on JIRA [0].
> > >>>>
> > >>>> Thanks,
> > >>>> Nick
> > >>>>
> > >>>> [0]:
> > https://issues.apache.org/jira/browse/HBASE-8693#comment-13711250
> > >>>>
> > >>>>
> > >>>> On Wed, Jul 17, 2013 at 1:42 AM, Matteo Bertozzi <
> > >> theo.bertozzi@gmail.com
> > >>>>> wrote:
> > >>>>
> > >>>>> I was looking at the HBASE-8693 patch, and looks good to me for the
> > >>>>> primitive types.
> > >>>>> but I can't see how do you plan to evolve stuff like the struct.
> > >>>>> By "evolve" I mean add/remove fields, or just query it with a
> subset
> > of
> > >>>>> fields.
> > >>>>> the fields don't have an id, and on read you must specify all of
> them
> > >> in
> > >>>>> the same order as you've used for write.
> > >>>>> (but maybe is just an immutable/fixed list of fields, and I'm ok
> with
> > >>>>> just
> > >>>>> adding that info to the comment on top of the class)
> > >>>>>
> > >>>>>
> > >>>>> Matteo
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Wed, Jul 17, 2013 at 12:39 AM, Nick Dimiduk <ndimiduk@gmail.com
> >
> > >>>>> wrote:
> > >>>>>
> > >>>>>> New patch posted. What do you think about the new isSkippable()
> and
> > >> the
> > >>>>>> associated limitation in Struct?
> > >>>>>>
> > >>>>>> I also posted some "dogfeed" per Enis's suggestion.
> > >>>>>>
> > >>>>>> -n
> > >>>>>>
> > >>>>>> On Fri, Jul 12, 2013 at 1:38 PM, Stack <st...@duboce.net> wrote:
> > >>>>>>
> > >>>>>>> On Fri, Jul 12, 2013 at 1:10 PM, Enis Söztutar <en...@apache.org>
> > >>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Did some chatting with Nick today.
> > >>>>>>>>
> > >>>>>>>> I think it is really important to get this right, and for that
> we
> > >>>>> would
> > >>>>>>>> definitely need more eyes towards it. The current patch set is
> > >> in a
> > >>>>>> good
> > >>>>>>>> state to bolster the discussion.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> I'll do another pass (Kicking others to give it a looksee too).
> > >>>>>>> St.Ack
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: Data types stage 1 is ready for reivew
Posted by Nick Dimiduk <nd...@gmail.com>.
On Sat, Aug 3, 2013 at 10:33 AM, Michael Segel <ms...@hotmail.com>wrote:
> How do you plan on enforcing data types within the engine?
>
Data types, at this point, are a client-side feature, not enforced by the
engine in anyway.
On Aug 1, 2013, at 10:57 PM, Matt Corgan <mc...@hotpads.com> wrote:
>
> > Looks great to me. Without the strict dependencies on hadoop or hbase
> > it'll be easy to pull into its own standalone module or new project if
> > there's demand.
> >
> >
> > On Thu, Aug 1, 2013 at 6:30 PM, Nick Dimiduk <nd...@gmail.com> wrote:
> >
> >> Finally-for-real-this-time patches posted. I'll take your +1's any time
> now
> >> ;)
> >>
> >> Thanks,
> >> Nick
> >>
> >> On Wed, Jul 24, 2013 at 11:27 AM, Nick Dimiduk <nd...@gmail.com>
> wrote:
> >>
> >>> Hi everyone,
> >>>
> >>> As of yesterday, I've posted "final" patched on both HBASE-8201<
> >> https://issues.apache.org/jira/browse/HBASE-8201>and
> >>> HBASE-8693 <https://issues.apache.org/jira/browse/HBASE-8693>. The
> >> former
> >>> specifies on-disk format and the latter is the user-facing API. If
> you've
> >>> already left me a review, thank you; please have another look at these
> >>> patches. If you have an opinion here and haven't voiced it, we're
> >>> approaching the "forever hold your peace" part of the ceremony.
> >>>
> >>> Thanks,
> >>> Nick
> >>>
> >>>
> >>> On Wed, Jul 17, 2013 at 9:33 AM, Nick Dimiduk <nd...@gmail.com>
> >> wrote:
> >>>
> >>>> Thanks for having a look. If you don't mind terribly, I responded to
> >> your
> >>>> comments on JIRA [0].
> >>>>
> >>>> Thanks,
> >>>> Nick
> >>>>
> >>>> [0]:
> https://issues.apache.org/jira/browse/HBASE-8693#comment-13711250
> >>>>
> >>>>
> >>>> On Wed, Jul 17, 2013 at 1:42 AM, Matteo Bertozzi <
> >> theo.bertozzi@gmail.com
> >>>>> wrote:
> >>>>
> >>>>> I was looking at the HBASE-8693 patch, and looks good to me for the
> >>>>> primitive types.
> >>>>> but I can't see how do you plan to evolve stuff like the struct.
> >>>>> By "evolve" I mean add/remove fields, or just query it with a subset
> of
> >>>>> fields.
> >>>>> the fields don't have an id, and on read you must specify all of them
> >> in
> >>>>> the same order as you've used for write.
> >>>>> (but maybe is just an immutable/fixed list of fields, and I'm ok with
> >>>>> just
> >>>>> adding that info to the comment on top of the class)
> >>>>>
> >>>>>
> >>>>> Matteo
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, Jul 17, 2013 at 12:39 AM, Nick Dimiduk <nd...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> New patch posted. What do you think about the new isSkippable() and
> >> the
> >>>>>> associated limitation in Struct?
> >>>>>>
> >>>>>> I also posted some "dogfeed" per Enis's suggestion.
> >>>>>>
> >>>>>> -n
> >>>>>>
> >>>>>> On Fri, Jul 12, 2013 at 1:38 PM, Stack <st...@duboce.net> wrote:
> >>>>>>
> >>>>>>> On Fri, Jul 12, 2013 at 1:10 PM, Enis Söztutar <en...@apache.org>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> Did some chatting with Nick today.
> >>>>>>>>
> >>>>>>>> I think it is really important to get this right, and for that we
> >>>>> would
> >>>>>>>> definitely need more eyes towards it. The current patch set is
> >> in a
> >>>>>> good
> >>>>>>>> state to bolster the discussion.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> I'll do another pass (Kicking others to give it a looksee too).
> >>>>>>> St.Ack
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
>
>
Re: Data types stage 1 is ready for reivew
Posted by Michael Segel <ms...@hotmail.com>.
Uhm...
Ok.
Silly question.
How do you plan on enforcing data types within the engine?
I did a quick read of the Jira, and there is a question of design philosophy that should be discussed.
On Aug 1, 2013, at 10:57 PM, Matt Corgan <mc...@hotpads.com> wrote:
> Looks great to me. Without the strict dependencies on hadoop or hbase
> it'll be easy to pull into its own standalone module or new project if
> there's demand.
>
>
> On Thu, Aug 1, 2013 at 6:30 PM, Nick Dimiduk <nd...@gmail.com> wrote:
>
>> Finally-for-real-this-time patches posted. I'll take your +1's any time now
>> ;)
>>
>> Thanks,
>> Nick
>>
>> On Wed, Jul 24, 2013 at 11:27 AM, Nick Dimiduk <nd...@gmail.com> wrote:
>>
>>> Hi everyone,
>>>
>>> As of yesterday, I've posted "final" patched on both HBASE-8201<
>> https://issues.apache.org/jira/browse/HBASE-8201>and
>>> HBASE-8693 <https://issues.apache.org/jira/browse/HBASE-8693>. The
>> former
>>> specifies on-disk format and the latter is the user-facing API. If you've
>>> already left me a review, thank you; please have another look at these
>>> patches. If you have an opinion here and haven't voiced it, we're
>>> approaching the "forever hold your peace" part of the ceremony.
>>>
>>> Thanks,
>>> Nick
>>>
>>>
>>> On Wed, Jul 17, 2013 at 9:33 AM, Nick Dimiduk <nd...@gmail.com>
>> wrote:
>>>
>>>> Thanks for having a look. If you don't mind terribly, I responded to
>> your
>>>> comments on JIRA [0].
>>>>
>>>> Thanks,
>>>> Nick
>>>>
>>>> [0]: https://issues.apache.org/jira/browse/HBASE-8693#comment-13711250
>>>>
>>>>
>>>> On Wed, Jul 17, 2013 at 1:42 AM, Matteo Bertozzi <
>> theo.bertozzi@gmail.com
>>>>> wrote:
>>>>
>>>>> I was looking at the HBASE-8693 patch, and looks good to me for the
>>>>> primitive types.
>>>>> but I can't see how do you plan to evolve stuff like the struct.
>>>>> By "evolve" I mean add/remove fields, or just query it with a subset of
>>>>> fields.
>>>>> the fields don't have an id, and on read you must specify all of them
>> in
>>>>> the same order as you've used for write.
>>>>> (but maybe is just an immutable/fixed list of fields, and I'm ok with
>>>>> just
>>>>> adding that info to the comment on top of the class)
>>>>>
>>>>>
>>>>> Matteo
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 17, 2013 at 12:39 AM, Nick Dimiduk <nd...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> New patch posted. What do you think about the new isSkippable() and
>> the
>>>>>> associated limitation in Struct?
>>>>>>
>>>>>> I also posted some "dogfeed" per Enis's suggestion.
>>>>>>
>>>>>> -n
>>>>>>
>>>>>> On Fri, Jul 12, 2013 at 1:38 PM, Stack <st...@duboce.net> wrote:
>>>>>>
>>>>>>> On Fri, Jul 12, 2013 at 1:10 PM, Enis Söztutar <en...@apache.org>
>>>>> wrote:
>>>>>>>
>>>>>>>> Did some chatting with Nick today.
>>>>>>>>
>>>>>>>> I think it is really important to get this right, and for that we
>>>>> would
>>>>>>>> definitely need more eyes towards it. The current patch set is
>> in a
>>>>>> good
>>>>>>>> state to bolster the discussion.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I'll do another pass (Kicking others to give it a looksee too).
>>>>>>> St.Ack
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
Re: Data types stage 1 is ready for reivew
Posted by Matt Corgan <mc...@hotpads.com>.
Looks great to me. Without the strict dependencies on hadoop or hbase
it'll be easy to pull into its own standalone module or new project if
there's demand.
On Thu, Aug 1, 2013 at 6:30 PM, Nick Dimiduk <nd...@gmail.com> wrote:
> Finally-for-real-this-time patches posted. I'll take your +1's any time now
> ;)
>
> Thanks,
> Nick
>
> On Wed, Jul 24, 2013 at 11:27 AM, Nick Dimiduk <nd...@gmail.com> wrote:
>
> > Hi everyone,
> >
> > As of yesterday, I've posted "final" patched on both HBASE-8201<
> https://issues.apache.org/jira/browse/HBASE-8201>and
> > HBASE-8693 <https://issues.apache.org/jira/browse/HBASE-8693>. The
> former
> > specifies on-disk format and the latter is the user-facing API. If you've
> > already left me a review, thank you; please have another look at these
> > patches. If you have an opinion here and haven't voiced it, we're
> > approaching the "forever hold your peace" part of the ceremony.
> >
> > Thanks,
> > Nick
> >
> >
> > On Wed, Jul 17, 2013 at 9:33 AM, Nick Dimiduk <nd...@gmail.com>
> wrote:
> >
> >> Thanks for having a look. If you don't mind terribly, I responded to
> your
> >> comments on JIRA [0].
> >>
> >> Thanks,
> >> Nick
> >>
> >> [0]: https://issues.apache.org/jira/browse/HBASE-8693#comment-13711250
> >>
> >>
> >> On Wed, Jul 17, 2013 at 1:42 AM, Matteo Bertozzi <
> theo.bertozzi@gmail.com
> >> > wrote:
> >>
> >>> I was looking at the HBASE-8693 patch, and looks good to me for the
> >>> primitive types.
> >>> but I can't see how do you plan to evolve stuff like the struct.
> >>> By "evolve" I mean add/remove fields, or just query it with a subset of
> >>> fields.
> >>> the fields don't have an id, and on read you must specify all of them
> in
> >>> the same order as you've used for write.
> >>> (but maybe is just an immutable/fixed list of fields, and I'm ok with
> >>> just
> >>> adding that info to the comment on top of the class)
> >>>
> >>>
> >>> Matteo
> >>>
> >>>
> >>>
> >>> On Wed, Jul 17, 2013 at 12:39 AM, Nick Dimiduk <nd...@gmail.com>
> >>> wrote:
> >>>
> >>> > New patch posted. What do you think about the new isSkippable() and
> the
> >>> > associated limitation in Struct?
> >>> >
> >>> > I also posted some "dogfeed" per Enis's suggestion.
> >>> >
> >>> > -n
> >>> >
> >>> > On Fri, Jul 12, 2013 at 1:38 PM, Stack <st...@duboce.net> wrote:
> >>> >
> >>> > > On Fri, Jul 12, 2013 at 1:10 PM, Enis Söztutar <en...@apache.org>
> >>> wrote:
> >>> > >
> >>> > > > Did some chatting with Nick today.
> >>> > > >
> >>> > > > I think it is really important to get this right, and for that we
> >>> would
> >>> > > > definitely need more eyes towards it. The current patch set is
> in a
> >>> > good
> >>> > > > state to bolster the discussion.
> >>> > > >
> >>> > > >
> >>> > >
> >>> > > I'll do another pass (Kicking others to give it a looksee too).
> >>> > > St.Ack
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>