| 19 | | Note this RFC originally explored using an Observer pattern as per implementations in Java [http://java.sun.com/j2se/1.4.2/docs/api/javax/imageio/event/IIOReadUpdateListener.html imageio update]. The RFC then also discussed the [http://www.gtk.org/api/2.6/glib/glib-Asynchronous-Queues.html Asynchronous Message Queue pattern], but after detailed discussions with [http://thread.gmane.org/gmane.comp.gis.gdal.devel/16409/focus=16630 Tamas Szekeres, Even Rouault, Adam Nowacki and Frank Warmerdam] an even simpler interface is proposed which wraps the more unpleasant developer tasks of operating with the streaming protocol but allows the user greater flexibility in interacting with the stream in their preferred language. This is implemented by using a context object to act as an intermediary between the user layer and the format driver. The approach recommended in the RFC is a half-way abstraction of the protocol as it requires some knowledge that this is a streaming format and how to optimise the driver from the user interface. This is an acceptable, and actually desirable trade-off, since it allows the swig wrappers to implement high speed data access / display in a pattern suitable for the language. The protocol may support a finer level of messaging than is available through this layer. |
| 20 | | |
| 21 | | Note that we may wish to revisit the name the classes within this RFC since with this proposal the the RasterIO, and block methods are blocking, hence there is not any asynchronous communication in the format driver and this is delegated to the user code layer. |
| | 19 | Note this RFC originally explored using an Observer pattern as per implementations in Java [http://java.sun.com/j2se/1.4.2/docs/api/javax/imageio/event/IIOReadUpdateListener.html imageio update]. The RFC then also discussed the [http://www.gtk.org/api/2.6/glib/glib-Asynchronous-Queues.html Asynchronous Message Queue pattern], but after detailed discussions with [http://thread.gmane.org/gmane.comp.gis.gdal.devel/16409/focus=16630 Tamas Szekeres, Even Rouault, Adam Nowacki and Frank Warmerdam] an even simpler interface is proposed which wraps the more unpleasant developer tasks of operating with the streaming protocol but allows the user greater flexibility in interacting with the stream in their preferred language. This is implemented by using a context object to act as an intermediary between the user layer and the format driver. The approach recommended in the RFC is a half-way abstraction of the protocol as it requires some knowledge that this is a streaming format and how to optimise the driver from the user interface. This is an acceptable, and actually desirable trade-off, since it allows the swig wrappers to implement high speed data access / display in a pattern suitable for the language. The protocol may support a finer level of messaging than is available through this format driver. |
| | 20 | |
| | 21 | Note that we may wish to revisit the name the classes within this RFC since with this proposal the RasterIO, and block methods are blocking, hence there is not any asynchronous communication in the format driver and this is delegated to the user code layer. |
