Hi Jody,
can you please cast a firm vote on this proposal?
It's not clear if you are still demanding something to be changed, or not,
and the proposal is stuck as a consequence
Cheers
Andrea
On Thu, Oct 17, 2019 at 9:17 PM Jody Garnett <jody.garn...@gmail.com> wrote:
> Thanks Andrea, I understand I am a bit late providing feedback.
>
> With respect to events, perhaps the interface stability aspect is
> addressed by the ability to add default methods.
>
> And I agree the pattern is: RenderListener listens for RenderEvents which
> may have a RenderEvent.Type (along with other state).
>
> I do not feel strongly, only want the stability aspect considered.
> --
> Jody Garnett
>
>
> On Thu, 17 Oct 2019 at 10:10, Andrea Aime <andrea.a...@geo-solutions.it>
> wrote:
>
>> On Thu, Oct 17, 2019 at 12:30 AM Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> Can I ask you to fill in the tasks section, want to be sure we have a
>>> clear picture of the work involved.
>>>
>>> You have events for the layer by layer notifications, and subsequent
>>> labeling activities, is there any need to have events for the composition
>>> steps (thinking of the rendering into multiple buffers and resulting alpha
>>> blending effects).
>>>
>>
>> No need at the moment, but you can make your own GSIP for it if you do?
>> :-)
>> Generally speaking it's bad form to ask others for scope increase, but
>> it's fundamental that we check
>> the proposed design does not prevent those future improvements.
>>
>>
>>> I tend to prefer notification with event enumerations, rather than
>>> "labellingStart" and "labellingEnd" which does not scale.
>>>
>>> Would you consider something along the lines of:
>>>
>>> public interface RenderListener {
>>> enum RenderEvent { START, UPDATE, END };
>>> default void layer( Layer layer, RenderEvent event ); // covers
>>> START, END
>>> default void labeling( RenderingEvent event ); // covers START, END
>>> default void composition( String name, RenderingEvent event ); //
>>> covers START, UPDATE, END
>>> default void rendering( RenderEvent event ); // covers START, END
>>> }
>>>
>>
>> Hum... does not really improve scalability IMHO, cuts in half the number
>> of methods, does not make them a order of magnitude
>> smaller or a fixed number. And things like "RenderEvent" are normally
>> objects carrying around the "change" information in listener
>> interfaces having a single listen method, rather than being a
>> classification... If we go for this design I'd call them EventType instead.
>> Given that there are default implementations, an implementor does not
>> really have to work though them, if interested in a single
>> even, they can implement just that method.
>>
>> My reaction to this is... meh... do you feel strongly about it? Not the
>> biggest deal to change the implementation, but honestly
>> I liked the interface as proposed better :-D
>>
>> Cheers
>> Andrea
>>
>> == GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
>> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
>> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
>> http://www.geo-solutions.it http://twitter.com/geosolutions_it
>> ------------------------------------------------------- *Con riferimento
>> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
>> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
>> circostanza inerente alla presente email (il suo contenuto, gli eventuali
>> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
>> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
>> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
>> sarei comunque grato se potesse darmene notizia. This email is intended
>> only for the person or entity to which it is addressed and may contain
>> information that is privileged, confidential or otherwise protected from
>> disclosure. We remind that - as provided by European Regulation 2016/679
>> “GDPR” - copying, dissemination or use of this e-mail or the information
>> herein by anyone other than the intended recipient is prohibited. If you
>> have received this email by mistake, please notify us immediately by
>> telephone or e-mail.*
>>
>
--
Regards, Andrea Aime == GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
------------------------------------------------------- *Con riferimento
alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto, gli eventuali
allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
