[MTOS-dev] [ProNet] Javascript Library Standardization

[Byrne Reese]

I have been corrected ­ YUI¹s files are versioned so that they won¹t change
out from under you.

But still ­ I would want to include these in the build as we do other 3rd
party dependencies.


On 1/23/08 2:48 PM, "Byrne Reese" <byrne at sixapart.com> wrote:

> I would never advocate point MT at a third party server. If we are to adopt a
> 3rd party library, then we will certify MT against a fixed version of that
> library. The risk introduced by allowing a third party to update MT¹s core
> javascript libraries, without our first testing them is astronomical.
> 
> Whatever we adopt must be licensed in a way that is compatible with Movable
> Type dual-licensing strategy, and must be shipped and bundled with the app.
> 
> Byrne
> 
> On 1/23/08 2:25 PM, "Chad Everett" <2008 at everitz.com> wrote:
> 
>> I don't disagree with that at all - I'm just saying that a lot of people seem
>> to say that the advantage of YUI is that it comes from the Yahoo servers,
>> when I'm not sure if that's much of an advantage is all.  I think that once
>> it's on a user's PC, it won't make much of a difference to the user.  Though
>> since Yahoo does use expire headers, and they update it, if the performance
>> is bad, it will be noticeable (yes, you can download it and host it yourself
>> - but who will do that?).  If you go get something else, and download it,
>> chances are you aren't going to update it unless you need to do so.
>> 
>> As to the particular framework, I think that it needs to be a solid process
>> if one will be chosen over others. JavaScript has been a pain to me lately,
>> and having to deal with which one is where and what effect it has on
>> performance is not my idea of fun right now...
>> 
>> --
>> Chad Everett
>> Everitz Consulting
>> 
>> 
>> Timothy Appnel wrote:
>>>  
>>> Chad I think you are overlooking browser caching here. Coming from one
>>> source the library should get pulled from the local cache no matter
>>> which site is using it.
>> 
>> 
>> _______________________________________________
>> MTOS-dev mailing list
>> MTOS-dev at sixapart.com
>> http://www.sixapart.com/mailman/listinfo/mtos-dev
> 
> 
> 
> _______________________________________________
> MTOS-dev mailing list
> MTOS-dev at sixapart.com
> http://www.sixapart.com/mailman/listinfo/mtos-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.sixapart.com/pipermail/mtos-dev/attachments/20080123/99942ec9/attachment.html