Sounds good except to the fact that it's better to not preload all those
renderers. I don't know which ones will be used by the process and which
not. Somehow I still feel this presents challenges to npm. I'll write some
doodles today to study it out.
tiistai, 6. marraskuuta 2012 15.01.14 UTC+2 Bradley Meck kirjoitti:
>
> This sounds like a shared state lookup. Document and specify an interface
> for the renderers ("webgl" and "2d" in this case). Once you have done that,
> in getContext
>
> Surface.prototype.getContext = function (name, options) {
> var renderer = this._renderers[name] // _ prefix is for implementation
> detail
> if (!renderer) {
> throw ...
> }
> renderer.getContext(this, options) // or similar api
> }
>
> And then developers could extend the surface with a different api, it
> could require direct access to _renderers or some helper function like
> surface._addRenderer(name, interface).
>
> On Tuesday, November 6, 2012 2:39:06 AM UTC-6, Henri Tuhola wrote:
>>
>> I teamed up with author of node-openvg, and we need to make a shared API
>> for videocontext handling. I'd like to keep it open as possible, so people
>> could extend it with their own renderers later.
>>
>> surface.getContext("webgl", options) - this should grab API that's
>> currently given by node-video.
>> surface.getContext("2d", options) - this should grab API that's provided
>> by node-openvg-canvas
>>
>> How to package it such that it's simple and easy to handle? Is it
>> possible without changing the API?
>>
>
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
