Data Access in YUI
Data access in YUI is fragmented and diverging, and is lacking a normalization layer to which Widget and application developers can develop and rely on.
Implement a layered approach where each layer adds higher-level concepts, normalizing to the layer below it:
Super light-weight transport base-modules which are simply a static function that performs the work (and probably calls a callback function).
A Transaction factory for each transport which returns an instance of a generic Transaction class. These factory functions would be provided in a separate module that would require the transport base-module they are providing transaction support for. The Transaction instances would provide events scoped to the specific transaction.
DataSource would add instantiability around each of the transports allowing for a modeling of external/remote resource. DataSource instances would retain configuration between requests and use that configuration as the defaults for each request; i.e. a DataSource instance would be used to make repeated calls to the same resource endpoint.
[Stakeholders] What do we think of the intended direction of the architecture for transport layering up to DataSource as the instantiable thing?
[Thomas] We feel JSONP and YQL are not structured in a way that migrates cleanly to that goal. What do you think would be the best idea for IO? To remove instantiability, copy the existing bad implementations, or something else?
[Ryan] You have specific goals for Get in 3.5.0. How would those plans be impacted by the proposed architecture?
Investigate what changes (if any) we can make to JSONP, YQL, Get, and IO to unify their approaches and align them with the future goals.
Deprecate instantiability of JSONP, YQL, and IO for 3.5.0 (before implementers get too invested in the new featureset). This would bring IO, JSON, and YQL more inline and decrease k-weight.
Remove event facade from
io-base; separate transport from the evented transaction layer. This should also remove k-weight and offer a high performance option for internal properties such as Mail and Front Page to use the transport API directly.
Investigate feasibility of abstracting request queuing, form serialization, and other IO features at the transaction factory or DataSource level. Where would file upload functionality live?
Shift to DataSource to act as the instantiable, normalized layer on top of transports XHR, XDR, Get, JSONP, YQL, etc. (no code change required for immediate support).
Reduced k-weight to
Normalized API to implementers, while transports layers are allowed to be different, since they are different mechanisms under the hood.
Full support for instantiability and event-facade bubbling via DataSource.
Simpler and more extensible architecture to support the layered approach.
Create a generic Transaction class which is augmented with EventTarget and provides the transaction-level events. This would allow each transport to return an instance of the same Transaction object, and also enables support for deferreds/promises.
Layer on the transaction support on top of the lower-level transports via a static factory method for each transport. This would be supplied in a separate module from the core transport functionality and would add the transaction-level event support through the use of a generic Transaction class instances.
DataSource factory method to switch transport types depending on configuration. (Then we can remove duplicate code in autocomplete-base.)
DataSource would also return these same Transaction objects, but also allow for DataSchema support.
Support additional transports like websockets, postMessage, others?
YQL and JSONP should follow this new pattern.
JSONP and YQL incorrectly model a request.
Transaction-level events and event bubbling don't play well together in IO.
autocomplete-sourcesought not to exist, DataSource should be doing this.