Skip navigation
Currently Being Moderated

Congrats on the new OSS site, some suggestions...

Feb 25, 2008 10:01 AM

Adobe folks: congratulations on this new open source site. It looks well done, and a good step for Adobe. I have a few suggestions:

(1) svn via https. Many of your customers will be behind corporate firewalls that may implement a transparent HTTP proxy. Some of these proxies (Symantec's enterprise firewall offerings, for example) do not understand Delta-V WebDAV methods used by subversion breaking svn over http. Consider using https to get around this and to marginally increase security (most svn users will cache ssl certificates, preventing a hypothetical, but unlikely man-in-the-middle injection of evil code into a checkout).

(2) Wiki-type offerings. Much of the site is very much producer-to-consumer distribution model; there may be value in increasing community contribution (e.g. documentation) above and beyond the forums.

(2) Some kind of source browsing (like Trac, for a good example of this done well in commercial open-source projects, look at Apple MacOSForge pages such as this: http://trac.calendarserver.org/projects/calendarserver ).

Sean Upton
 
Replies
  • Currently Being Moderated
    Feb 25, 2008 5:21 PM   in reply to (Sean_Upton)
    Sean,

    Thanks for the feedback. We definitely appreciate the suggestions. To respond in more detail:
    1) I'll have the team look into https. I'm not sure how difficult that might be

    2) We are definitely going to be opening up parts of the site to more user comment than is currently available. On the other hand, I think some of the information is oriented around outbound communications, such as what our coding standards are.

    3 (aka, the second number 2) -- Absolutely. We were working on this but just didn't get it set up correctly in time for launch. It will likely appear in the next month or two.

    phil
     
    |
    Mark as:
  • Currently Being Moderated
    Feb 26, 2008 6:18 AM   in reply to (Sean_Upton)
    Great to hear about the upcoming source tree browsing! And congratulations to Adobe for this very positive move - although I'd personally like to see the term "software freedom" used instead of "open source" :-)

    I have a suggestion for an existing Adobe project that could be brought into this site: The Adobe Open Type Font Developer Kit has a lot of Python programs licensed under the BSD license, but some proprietary C programs too. It would be great if the AOTFDK could be fully freed and hosted on this new area! :-)
     
    |
    Mark as:
  • Currently Being Moderated
    Feb 26, 2008 6:55 AM   in reply to (Sean_Upton)
    Hi,<br /><br />I think the best place to post your request is the forum dedicated to the FDK:<br />http://www.adobeforums.com/cgi-bin/webx?14@@.ef93cf5<br /><br />Phil<br /><br /><br />On 2/26/08 6:18 AM, "Dave Crossland" <member@adobeforums.com> wrote:<br /><br />A new message was posted by Dave Crossland in<br /><br />Website --<br />  Congrats on the new OSS site, some suggestions...<br /><br />Great to hear about the upcoming source tree browsing! And congratulations to Adobe for this very positive move - although I'd personally like to see the term "software freedom" used instead of "open source" :-)<br /><br />I have a suggestion for an existing Adobe project that could be brought into this site: The Adobe Open Type Font Developer Kit has a lot of Python programs licensed under the BSD license, but some proprietary C programs too. It would be great if the AOTFDK could be fully freed and hosted on this new area! :-)<br /><br />________________________________<br />View/reply at Congrats on the new OSS site, some suggestions... <a href=http://www.adobeforums.com/webx?13@@.3c0639b9/1><a href=http://www.adobeforums.com/webx?13@@.3c0639b9/1><br />Replies by email are OK.<br />Use the unsubscribe <a href=http://www.adobeforums.com/webx?280@@.3c0639b9!folder=.3c060be4> <a href=http://www.adobeforums.com/webx?280@@.3c0639b9!folder=.3c060be4>   form to cancel your email subscription.
     
    |
    Mark as:
  • Currently Being Moderated
    Feb 26, 2008 7:28 AM   in reply to (Sean_Upton)
    Many thanks!
     
    |
    Mark as:
  • Currently Being Moderated
    Feb 26, 2008 10:05 AM   in reply to (Sean_Upton)
    David Lemon got back to my email I sent earlier before spotting the publication of this website; sadly there are no plans as yet to release the C programs.
     
    |
    Mark as:
  • Currently Being Moderated
    Dec 4, 2008 10:03 PM   in reply to (Sean_Upton)
    I'd like to offer some feedback on the coding "Flex SDK coding conventions and best practices"

    (I'd actually like to rewrite the whole thing and remove failures)

    haha, actually just a couple of points and questions:

    what's the benefit of

    if()
    {

    }

    as opposed to:

    if() {

    }

    If we're getting strict about code formatting standards the same set of semantics should apply accross the board ie: keeping per line character count to less than or equal to 80 for minimizing horizontal scrolling. Why not minimize extraneous nonsensical whitespace that actually decreases in readability in large programs with high levels of nested functions and operations?

    If opened for discussion a tighter set of constraints can be developed which would actually contribute more to rapid development practices. (and less funky looking code)

    I'm not sure if you've ever had to deal with gibberish like this in some *ah hehm* developers code...

    if()
    {
    if()
    {
    if()
    {
    if()
    {
    if()
    {

    }

    }

    }

    }

    }

    just the difference in vertical whitespace alone is worth considering this... - even though i would still freak out if i saw anyone on my team coding without proper nesting. I'd make them write python for a week or two to "learn them a lesson".

    if() {
    if() {
    if() {
    if() {
    if() {
    }
    }
    }
    }
    }

    ps I totally hijacked this topic - apologies. I can create a new one if this is worth following up on...
     
    |
    Mark as:
  • Currently Being Moderated
    Dec 5, 2008 8:11 AM   in reply to (Sean_Upton)
    While the formatting wasn't preserved in your post, I get what you're trying to demonstrate. However, I personally disagree that same-line styled braces improves readability and don't see next-line braces as a waste of vertical whitespace but rather something that provides essential eye room. That said, this really is just a personal preference which happened to match the critical mass that was reached many years ago when the first team members established the convention. Given the amount of code that exists, and that we've successfully established _a_ convention, we wouldn't consider changing something like this at this point.
     
    |
    Mark as:
  • Currently Being Moderated
    Dec 5, 2008 11:48 AM   in reply to (Sean_Upton)
    I didn't attempt to preserve formatting in that post intentionally to illustrate some poor code I've encountered.
    Everyone has their preference, I've found that in lengthy programs the vertical scrolling gets ridiculous really fast. Right from the start a program that consists of five functions and twenty if statements gets 25 extra line breaks, add else blocks and it gets a little silly.

    I can't see the benefit: the visual que from a rapid access point of view actually favors omitting extraneous line breaks:

    eg:

    if()
    {

    }
    else
    {

    }
    // 8 lines
    vs.

    if() {

    } else {

    }
    //5 lines

    b Next issue then:

    function f(a:Array /* of Number */):Array /* of Object */
    {
    ...
    }

    This I have an actual legitimate issue regarding rapid development and corporate implementation guidelines that are pretty prevalent (at least in my 11 or so years of development)

    b case in point:

    For a particular change order made to some integral part of a hypothetical proprietary business application.

    /*
    // Change order #011198
    // Client[Client Name] requested return value changed to unsigned integer from array.
    // 12/5/2008 2:30pm montana p montana@email.com
    .*/

    function f(a:Array /* of Number */, i:uint ):uint /* of Object */
    {
    return uint;
    ...
    }

    /*
    function f(a:Array /* of Number */):Array /* of Object */
    {
    return array;
    }
    .*/

    b ^ this obviously doesn't work, and costs more money to do since the programmer must take the time to edit out the nested comment blocks, or use // single line comments

    b The preferred method is:

    // usage: f(Array of Number);
    function f(a:Array):Array { /* of Number */
    return array;
    }

    The resultant change:

    /*
    // Change order #011198
    // Client[Client Name] requested return value changed to unsigned integer from array.
    // 12/5/2008 2:30pm montana p montana@email.com
    .*/

    // usage: f(Array of Number, uint);
    function f(a:Array, i:uint):uint {
    return i;
    }

    /*
    // usage: f(Array of Number);
    function f(a:Array):Array {
    return array;
    }
    .*/

    b this method has the added benefit of adding rudimentary documentation for the function call itself

    There's always room for improvement. Saying "we already have so much code formatted x way so we shouldn't change our practices", even if there may be value to doing so, is no good. I understand the hesitance. However, if there is evidence supporting a particular design pattern's
    inherent value, it should be considered notwithstanding existing methodologies.

    thank you for your time, I look forward to more amazing work from the adobe team.

    (sorry about not taking the time to format this post a little nicer...back to work)
     
    |
    Mark as:
  • Currently Being Moderated
    May 14, 2009 10:59 AM   in reply to (Sean_Upton)

    Yea no doubt, great job with the forum guys

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 28, 2010 11:41 PM   in reply to (Sean_Upton)

    Well done job!

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)