HTTPS clone URL

SSH clone URL

Data Access in YUI

Problem Statement

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.

Proposed Solution

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.

Questions

[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?

Short-Term Roadmap

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?

Short-Term Benefits

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.

Longer-Term Roadmap

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.