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
io-base,jsonp, andyql. -
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.
-
Improved learnability.
-
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.