Return-Path: X-Original-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4F282C7D6 for ; Fri, 13 Jul 2012 14:12:06 +0000 (UTC) Received: (qmail 88826 invoked by uid 500); 13 Jul 2012 14:12:05 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 88789 invoked by uid 500); 13 Jul 2012 14:12:05 -0000 Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: flex-dev@incubator.apache.org Delivered-To: mailing list flex-dev@incubator.apache.org Received: (qmail 88643 invoked by uid 99); 13 Jul 2012 14:12:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jul 2012 14:12:04 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.214.47] (HELO mail-bk0-f47.google.com) (209.85.214.47) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jul 2012 14:11:58 +0000 Received: by bkcik5 with SMTP id ik5so2446232bkc.6 for ; Fri, 13 Jul 2012 07:11:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=3vLkBI0T6RYoNbQxEVkq22xqsvpH9645i6u/K2GapkY=; b=QjMKQPg0RsuvHq7TmoXuMqDP4Ib0jFZONk2CUyaLWAT14guxbYgVDqLKIZTDtztGW2 22kq0mB4rYmYTQl9nUX43oYu/wcr+d0qYyDNptomn7kDAp6j1aeM2G0Urli80ecESOYr mqtb0lwVnc3/3bGZIfNEUESvVuTx9hQnMV/S5TMKAM4Z6Q+Inje/UOdVHuGFC0QZqD2n WLJsAuBRLeA/L/bUAs9Az5Bi8thZjzyQ1GyhMgahpBCrFe1NWk28urGPcZoeSibAXpeu KWwwcVlF+oC6HNYLBj+9LlvN1licuAh1nKaYzTvFOKymNQ0zhUpH+dWVi8K3Aq7E5P76 bBHA== MIME-Version: 1.0 Received: by 10.205.127.131 with SMTP id ha3mr971292bkc.123.1342188697432; Fri, 13 Jul 2012 07:11:37 -0700 (PDT) Received: by 10.204.201.140 with HTTP; Fri, 13 Jul 2012 07:11:37 -0700 (PDT) X-Originating-IP: [35.8.29.149] In-Reply-To: References: <405376D2-9EF6-4F20-BFF9-BD56898C8BDF@buzzware.com.au> <4FFC354A.906@dot-com-it.com> <4FFC3E7A.8040403@dot-com-it.com> <4FFCA15D.1020401@dot-com-it.com> <4FFECCCA.90404@dot-com-it.com> Date: Fri, 13 Jul 2012 10:11:37 -0400 Message-ID: Subject: Re: Suggestion : Adopt a package manager like Ruby Gems for Flex as a first class citizen of the SDK From: Nicholas Kwiatkowski To: flex-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=0015173fe4ac8833c504c4b6a8a5 X-Gm-Message-State: ALoCoQkgZ2buWi98B+KkBnJiSgzu0gKFhMbkUzyAHXyGMhNfURsnlIqe8wdp3trwYxn+uS2swQBG --0015173fe4ac8833c504c4b6a8a5 Content-Type: text/plain; charset=ISO-8859-1 Yi, I think very few people were advocating that we NOT have a packing manager, but rather adopting the two proposed solutions may not be the way to go. I personally think that if/when a package manager is decided on, it be one with very little barrier to entry. The gem system works very well for ruby developers, because they already have all the prerequisites installed on their machines. It is just one additional tool that they have in their toolkit. For us to require another tool that has tons of other dependencies, we are just raising that barrier to entry to do Flex programming. If I require somebody to install Node.JS (and its dependancies, and configure it, and keep it patched, etc), that is a huge burden for something that really isn't required to do programming in Flex (and maybe only to use certain OSS libraries and projects). Why couldn't we create a package manager out of AIR/Flex? Sure, doing things in command-line is pretty limited, but in all honesty, we have very command-line developers... I would venture to say 95% use some sort of IDE on Windows or Mac. If we /needed/ a command-line app, one could be written in C/C++ so that the requirements are very low. The nice thing about Flex is that our "packages" (gem-likes), are compiled into the final app, where as in Ruby, PHP and others that require package managers, the end-user also needs to install those components in order for the app to work. It really only needs to be a developer tool, and an end-user tool. -Nick On Fri, Jul 13, 2012 at 9:48 AM, Yi Tan wrote: > Hi all, > > I've been following this maillist for months. I seldom post, because my > English is self-taught. I try my best to express myself simple and clearly. > > This post does make me feel a bit sad when seeing 6 of 12 replies against > adopting a package manager in Flex. > > Programming has already become a social activity. In a community with > decent tools, programmers share, learn with each other and eventually be > able to make better software in much less time. This is the trend I really > hope Flex/ActionScript could catch up with, because the major part of my > daily job is coding in AS. > > /* 1. Why a package manager matters */ > > A real story: we are working on a game app by using AIR for iOS. To reduce > memory consumption, I need something can make skinnable interface from > little bitmaps snippets (oh, no Flex framework, it's too enterprise to be > fit in real-world apps). So I googeled and found a few scale bitmap AS > classes. After comparing them, I chose ByteArray.org's one ( > http://www.bytearray.org/?p=118) . A few days after using that class, I > found it is not well-thought, there was no need to duplicate the original > bitmap data. So I wrote my own. The funny thing was when I am about to push > my version of ScaleBitmap onto github. I found there is a newer version > of ByteArray.org's already on github and it did exactly the same thing as I > did :( (http://www.bytearray.org/?p=1206). Because that blog post is > newer, it ranked lower in google search result, and I missed it. So I > wasted half day building a same thing and writing test cases for it. > > If flex has a decent package manager, programmer can share and maintain > code libraries in a centralized-managed place. And that will also be the > best place for all AS programmers to find out is there already some smart > guys done what I'm going to do. > > /* 2. Why Ruby, Python, JS, Perl... whatever script language need */ > > The answer is so obvious: AVM can not do that job. > > AVM is designed to performer heavy multimedia tasks under limited > resources. It is the best in that filed, but it's not a general purpose VM. > There is no CLI, no REPL, no script ability in AVM. > So when you need something that can talk in command line on-the-fly, you > have to look on other scriptable virtual machine, and thus other languages. > > For this point, I would recommend nodejs. It's built on V8 engine, reads > javascript, which is familiar to ActionScript 2, and npm is just so easy to > use: http://npmjs.org/ > Also for Ruby-friendly people, coffee-script is awesome. > > /* 3. What a decent package manager should be */ > > at least: > - It should let people publish their libs in a few simple steps > - It should let people search other people's libs in a few simple steps > - It should let lib owners maintain there libs in a very easy way > - It will be great if it can be integrated with github > > > Regards, > > ty > > > On Fri, Jul 13, 2012 at 4:46 PM, John Fletcher > wrote: > > > 2012/7/12 Jeffry Houser : > > > It does not affect my point. But, as I understood it; most people use > > Ruby > > > today for the server-side of a web site (or other application). > > > > Probably true. It's most commonly used with Rails, which is a > > server-side framework built on top of Ruby. > > > > > I can > > > install any given application server on my local machine, that doesn't > > make > > > it less of a server.. > > > > True. But in this case we're only talking about the part that really > > isn't a server. It's like depending on Java, as opposed to depending > > on Tomcat (a server technology built with Java). > > > > But this is all academic. I think most agree with you that we don't > > want to introduce other dependencies. But if someone could write this > > tool in ActionScript (not sure if that's feasible) then you would > > probably have a lot of support on your hands. > > > > John > > > --0015173fe4ac8833c504c4b6a8a5--