[framework-one] Repository change for FW/1 ** IMPORTANT **

[Sean Corfield]

After much consideration I have decided to move FW/1 from the RIAForge
svn repository to github.com. I've been using git heavily on a client
project for about nine months and I'd been using it before then when
collaborating with Ron Hopper on cfSpec. A lot of the (mostly
non-CFML) projects I work with these days are using github.com now and
as FW/1 continues to gain in popularity, I want to make it easier for
others to provide input and ideas which github allows easily.

I've imported the current svn repository - with all history - to
github.com here:

http://github.com/seancorfield/fw1

(Ryan, I imported you as Ryan Cogswell <ryanco...@gmail.com> - I
don't know if you have a github.com account?)

I'll be updating the RIAForge site over the next few days to point all
the links over to github and I'll be migrating the wiki as well.
Essentially FW/1 1.1 will launch from github.com and all future
development will be from there.

FWIW, Andy Jarrett and AJ Mercer have a security models projects on
github.com for FW/1:

http://github.com/andyj/FW-1-Security-Models/
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

--
You received this message because you are subscribed to the Google Groups "framework-one" group.
To post to this group, send email to framew...@googlegroups.com.
To unsubscribe from this group, send email to framework-on...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/framework-one?hl=en.

[John Allen]

Why the switch? 

Like GIT that much better? 

github that much better than riaforge?

[Judith Barnett]

This is very good news. I was just wishing last night that FW/1 was in Git.

On Fri, Apr 30, 2010 at 7:04 PM, Sean Corfield <seanco...@gmail.com> wrote:
> After much consideration I have decided to move FW/1 from the RIAForge
> svn repository to github.com.

[George Eapen]

I am glad to see this change and it'll make it easier to submit examples and check the version changes. RIAForge looks like it needed a manual update for the version update so it was hard to tell when the commits were made.

[Kevin Pepperman]

Good move Sean, I think GIT fork is especially approachable for people not familiar with Version control.

And is a heck of a lot simpler when all you are doing is forking a file to contribute.

github is very simple, and fork you doesn't require a manual. :)

--
/Kevin Pepperman

"They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." - Benjamin Franklin

[Javier Julio]

Brilliant move! I support it. For those that haven't tried Git or Github, you'll love it once you do. It's a great site and makes it easy to version your apps as well as share it with others. I started to use it back in January for any of my projects. No offense to riaforge which is a great site but definitely prefer Github. Thanks for the heads up Sean! Great move!

Ciao!
Javi

--
Javier Julio
Senior Flex Developer, 9mmedia
www.javier-julio.com

[Jamie Krug]

Sean,

I'll definitely add my "+1" for git/github! I've been getting very
excited about git, in general, and just spent merely 15 minutes to
learn the basics of github. I created my account, forked FW/1,
committed a change, pushed it to my (forked) project and sent you a
pull request!

For all others, I thought I'd point out the issue of keeping
consistent line endings in any project. In short, Windows uses CRLF
(carriage return/line feed, or \r\n) for line endings, while the rest
of the universe uses LF (just line feed, or \n). This is generally
harmless, but to avoid various folks committing or seeing different
types of line endings in the files and mucking up the project with
commits that merely use different line endings without any real code
change, we all need to pay attention.

The solution is quite simple (as outlined http://help.github.com/dealing-with-lineendings/).
Basically, everyone should set the git global config "core.autocrlf"
setting; Mac/Linux users can set it to "input" to avoid introducing
CRLF line endings pulled from a Windows developer, and Windows users
can set it to "true" to ensure commits are always LF.

I.e., issue one of the following commands...

Windows users:
git config --global core.autocrlf true

Mac/Linux users:
git config --global core.autocrlf input

Cheers,
Jamie

On Apr 30, 10:04 pm, Sean Corfield <seancorfi...@gmail.com> wrote:
> After much consideration I have decided to move FW/1 from the RIAForge

> svn repository to github.com. I've been usinggitheavily on a client

> project for about nine months and I'd been using it before then when
> collaborating with Ron Hopper on cfSpec. A lot of the (mostly
> non-CFML) projects I work with these days are using github.com now and
> as FW/1 continues to gain in popularity, I want to make it easier for
> others to provide input and ideas which github allows easily.
>
> I've imported the current svn repository - with all history - to
> github.com here:
>
> http://github.com/seancorfield/fw1
>

> (Ryan, I imported you as Ryan Cogswell <ryancogsw...@gmail.com> - I

> don't know if you have a github.com account?)
>
> I'll be updating the RIAForge site over the next few days to point all
> the links over to github and I'll be migrating the wiki as well.
> Essentially FW/1 1.1 will launch from github.com and all future
> development will be from there.
>
> FWIW, Andy Jarrett and AJ Mercer have a security models projects on
> github.com for FW/1:
>
> http://github.com/andyj/FW-1-Security-Models/
> --
> Sean A Corfield -- (904) 302-SEAN

> Railo Technologies, Inc. --http://getrailo.com/
> An Architect's View --http://corfield.org/

[Sean Corfield]

On Fri, May 7, 2010 at 11:26 AM, Jamie Krug <jami...@gmail.com> wrote:
> I'll definitely add my "+1" for git/github! I've been getting very
> excited about git, in general, and just spent merely 15 minutes to
> learn the basics of github. I created my account, forked FW/1,
> committed a change, pushed it to my (forked) project and sent you a
> pull request!

Pulled and merged.

> For all others, I thought I'd point out the issue of keeping
> consistent line endings in any project. In short, Windows uses CRLF
> (carriage return/line feed, or \r\n) for line endings, while the rest
> of the universe uses LF (just line feed, or \n).

Another thing to bear in mind: DO NOT MAKE SPURIOUS WHITESPACE OR
LAYOUT CHANGES!

If you are adding functionality and change the whitespace, indentation
or { } layout of surrounding lines, it makes it nearly impossible for
me to figure out what you've really changed and it makes it impossible
to pull & merge changes from your repo.

I was trying to pull in Brett's changes but I've had to give up (after
spending half an hour on it) because Brett had added lots of
whitespace, both between lines and within lines - and had changed
lowercase operators (eq, not) to UPPERCASE (EQ, NOT). In the end it
was absolutely impossible to figure out what was really changed and
what was just noise in terms of Brett's whitespace preferences.

When you're modifying someone else's code, you must be consistent with
what they've done in terms of style - changing existing code just to
suit your layout preferences is counter-productive.

Sorry if it sounds like I'm picking on Brett here but he'd added a
hook for implementing routes and I wanted to try it out but I could
not make the merge work because of all the other changes.

Another tip: make your commits as small as possible. If a commit
contains a small change, I can easily review it and apply it. If a
commit contains several changes, it's very hard to review and is more
likely to conflict.

That said, I'm glad to see enough interest that we're already seeing
forks on github. With the guidelines above, it'll help me coalesce
changes back into the core.

I've added both Jamie's and Brett's repos as remotes so I can pull all
their changes and keep track of the network locally (via GitX - highly
recommended if you're on a Mac).

--
Sean A Corfield -- (904) 302-SEAN

Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

[Brett]

I'll get my act together Sean :) I do tend to fiddle with the little
things and will fight the urge. Is there anyway I can clean up my
mess in a way you can get a handle on it?

As more people get involved we might want to think about putting up a
coding conventions page on the wiki.

I'm loving the framework, but I think the code can be cleaned up quite
a bit and that would also help with these issues moving forward. I'll
even volunteer to do it if we can put together a quick list of
conventions. Wheels has some posted: http://cfwheels.org/docs/chapter/coding-guidelines

I was also curious if there are any unit tests writing for FW/1? I
did change quite a bit and am a little uneasy knowing my changes might
get pulled into the master.

For anyone wanting to jump in and are running on Windows, I found this
tut to be particularly useful:
http://wiki.github.com/multitheftauto/multitheftauto/how-to-use-tortoisegit

.brett
On May 7, 3:48 pm, Sean Corfield <seancorfi...@gmail.com> wrote:

> Railo Technologies, Inc. --http://getrailo.com/
> An Architect's View --http://corfield.org/

[Sean Corfield]

On Fri, May 7, 2010 at 1:16 PM, Brett <webf...@gmail.com> wrote:
> Is there anyway I can clean up my
> mess in a way you can get a handle on it?

I don't know. But starting with a fresh copy of FW/1 and only making
the route changes would at least let me look at the implications of
what you're trying to do :)

Also, working with git is very different to SVN. git commits can (and
should) be very small, isolated changes (preferably working changes
but not necessarily :). Pushes should be of collections of commits
that together make up a single working new feature. I pulled your
Google Groups link in README because it was a clean, simple commit.
But your route commit changed a lot of code that wasn't relevant. You
also introduced methods out of alphabetical order (although method
insertion is an easy thing to merge - I'd just commit that and then,
in a separate commit, move the method to where it should be).

> As more people get involved we might want to think about putting up a
> coding conventions page on the wiki.

Just follow the coding conventions already in the code.

That's a standard "best practice" in open source: you follow what's
already there and you do not change surrounding code.

> I'm loving the framework, but I think the code can be cleaned up quite
> a bit and that would also help with these issues moving forward.

Ryan has done a great job of "cleaning up" whilst keeping the style
consistent so I'd like others to follow his lead.

When you work on open source projects, part of the benefit is learning
to subdue your own preferences and follow those expressed by the
existing code and project leads. What looks like "cleaning up" to you
might be horrible style to them. That applies to whitespace, braces,
capitalization, naming conventions and so on. That's a good skill for
team development in general, whenever you join a project that is
already in progress.

Trying to change an existing project's "style" is usually an exercise
in frustration (for everyone involved).

> I was also curious if there are any unit tests writing for FW/1?

I'd be very interested in folks contributing unit tests. Due to the
nature of FW/1 - a single component that must be extended and whose
behaviors are mostly side-effects on the request lifecycle - it isn't
as easy to write tests for as you might think. I did at one point try
to write some cfSpec tests but didn't get very far.

FWIW, John Paul Ashenfelter ran into the same problem trying to write
unit tests for Fusebox.

That's not to say frameworks are inherently hard to test, but some of
FW/1's principles run counter to best practices for testability - and
a framework's internal principles are not (generally) reflective of
best practices for application code, since frameworks have to jump
thru some weird hoops in order to make it easier for developers to use
the framework.

--
Sean A Corfield -- (904) 302-SEAN

Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

[Peter Bell]

On May 8, 2010, at 7:15 AM, Sean Corfield wrote:

> I'd be very interested in folks contributing unit tests. Due to the
> nature of FW/1 - a single component that must be extended and whose
> behaviors are mostly side-effects on the request lifecycle - it isn't
> as easy to write tests for as you might think. I did at one point try
> to write some cfSpec tests but didn't get very far.

Generally when it's hard to write tests for a framework, one way to solve that is to create a small example application that exercise elements of the framework and to write tests for the exercising of the framework via testing the sample app. It's not a panacea and still you may well find more of the tests are acceptance level, but it's not a bad starting point.

Best Wishes,
Peter

[Brett]

> Just follow the coding conventions already in the code.

Problem is I don't know what those are. Why are some functions
written entirely in cfscript and some with cfml. Another one I
noticed is that sometimes arguments are scoped inside functions some
times they are not.

Putting functions in alphabetic order, GTK.

thanks,

.brett



On May 7, 5:15 pm, Sean Corfield <seancorfi...@gmail.com> wrote:

> Railo Technologies, Inc. --http://getrailo.com/
> An Architect's View --http://corfield.org/

[Ryan Cogswell]

> Why are some functions
> written entirely in cfscript and some with cfml.

The preference is for cfscript, but we are also maintaining backwards
compatibility with older cf versions (I believe a couple people are
using FW/1 with CF 7). This means there are a lot of things that we
cannot do using cfscript.

> Just follow the coding conventions already in the code.
>> Problem is I don't know what those are.

If some aspect is completely inconsistent, then chances are it's an
aspect of code style that we don't feel very strongly about. For
those things that are largely consistent in the current code, try to
maintain the consistency. If there's something that seems consistent,
but to which you have strong objections (for reasons beyond
aesthetics) -- ask about it. So long as you keep your changes as
isolated as possible and as consistent as possible with the existing
code, it will be easy for Sean to merge and clean up as he sees fit.
The easiest way to refine your knowledge of the code style aspects we
care about are to pay attention to what Sean bothers to change.

In general, I find documenting coding conventions to not be very
useful. The easiest things to document clearly are also the most
obvious aspects to glean from looking at the code. The more subtle
aspects are very difficult to document clearly and also tend to
gradually evolve as the code matures and as the styles of the
contributors evolve. I think that kind of gradual evolution is a good
thing and trying to document every last detail of the coding style
stunts this evolution and also results in documents that are so long
and pedantic that no one wants to read or maintain them.

Ryan

[Jamie Krug]

Well said! Agreed. Thanks, Ryan.

[Brett]

Okay, I'm going to reset my branch and then create a new project that
extends FW/1. I'm going to try to keep all new functionality in the
new project and only make minor changes to framework.cfc, and only if
needed. Overwriting the functions isn't a big deal.

thanks,

.brett

On May 7, 9:07 pm, Jamie Krug <jamiek...@gmail.com> wrote:
> Well said! Agreed. Thanks, Ryan.
>

> > framework-on...@googlegroups.com<framework-one%2Bunsu...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/framework-one?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "framework-one" group.
> To post to this group, send email to framew...@googlegroups.com.
> To unsubscribe from this group, send email to framework-on...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/framework-one?hl=en.

[Sean Corfield]

On Fri, May 7, 2010 at 2:37 PM, Brett <webf...@gmail.com> wrote:
> Problem is I don't know what those are.  Why are some functions
> written entirely in cfscript and some with cfml.

CFMX7 and Open BlueDragon are target audiences so the code must be
compatible with them (started on the requirements page). FW/1 2.0 will
be entirely cfscript and will only run on CF9/Railo and whichever
version of OpenBD supports that.

Optional arguments are not possible in cfscript for CFMX7/OpenBD.

> noticed is that sometimes arguments are scoped inside functions some
> times they are not.

When the function is entirely or mostly cfscript, arguments. is not
used because cfargument is not used to declare the arguments. It's
actually pretty consistent in the code. Someone opened a ticket
because they wanted arguments. everywhere and I answered that and
closed it.

> Putting functions in alphabetic order, GTK.

:)

Public in alpha order then private in alpha order. But bear in mind
CFMX7/OpenBD cfscript can't declare cfscript functions private :)

--
Sean A Corfield -- (904) 302-SEAN

Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

[Mike Henke]

John Allen asked: github that much better than riaforge?

I don't think it is a question of one verses the other. They
complement each other such as Riaforge and Google Code.

Ray will disagree but my take is Riaforge is great for a placeholder/
marker of an Adobe open source project. Riaforge does has features to
help open source project such as svn repositories, ticket system, etc
but Github is built specifically for open source source project
COLLABORATION. It is kinda like a product versus a feature.

I am excited to see a major CF project make the jump to Github.

@Sean Maybe a blog post eventually on how the process to move over
code and tickets along with updates on how it is going.

[Sean Corfield]

On Thu, May 13, 2010 at 8:21 AM, Mike Henke <henk...@gmail.com> wrote:
> John Allen asked: github that much better than riaforge?

One of the big differences is simply git vs svn - some people prefer
one, some people prefer the other. I've been using a variety of VCS
systems over the years: sccs, rcs, cvs, VSS (yes, at one company, for
one project, and it sucked!), Perforce (at adobe - it's their
corporate standard), svn and git. Of all those, git is my current
favorite but Perforce is a great option for corporate environments.
macromedia.com was managed with cvs. I don't know if Adobe uses svn
internally at all. I know some of their evangelists use git for demo /
open source projects that are delivered to the community.

> I am excited to see a major CF project make the jump to Github.

*blush*

I didn't actually think FW/1 was the first 'major' project to make the
jump (I don't view it as a 'major' project either, but thanks!).

> @Sean Maybe a blog post eventually on how the process to move over
> code and tickets along with updates on how it is going.

Yes, definitely. Right now, the wiki, issues and code are all moved
over, leaving just the forums and (small) blog on RIAForge. I plan to
shut the forums down since they don't get much traffic (and I hate web
forums anyway!). I'll migrate the important blog content over to my
personal blog in the fw1 category at some point.

I only moved open issues (so I had to make a judgment call on losing
the closed issue history) and the wiki was a bit of a pain because
Canvas (RIAForge) and github use different markdown formats (but
that's true whenever you move from one wiki to another). I was glad I
only had to migrate four pages!

--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Sean Corfield]

On Thu, May 13, 2010 at 8:21 AM, Mike Henke <henk...@gmail.com> wrote:

> but Github is built specifically for open source source project
> COLLABORATION.  It is kinda like a product versus a feature.

To pick up on this, github lets other developers fork your project and
extend it and then notify you of their changes which you can apply to
your master.

The last four commits on FW/1 have come from Brett's fork (webflint)
and I've been able to apply them with a click of a button after
reviewing them. Thanx Brett!

The changes are:
* Add link to Google Group in README.txt
* Make unhandled extensions and Flex gateway paths configurable (I'll
probably change the flexGatewayPath to allow a list of paths)
* Fix bug in cfcFilePath() on root file paths
* Add getConfig() to return the framework configuration (I'll probably
make this do a structCopy() so the configuration is readonly outside
the framework)

The change before those was from Jamie Krug's fork and fixed CRLF
issues in some files.

THAT is the power of git!

--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Mike Henke]

Or lets say Sean takes a 3 month vacation and doesn't work on FW1.
People might start going to Brett's fork (webflint) that is still
being actively developed. You know how open source creator's
priorities shift. Why should the project remain dormant if the
creator is off to other things?

There could even be changes that are deemed outside the FW1 scope so
not incorporated in Sean's repository yet some people may want those
so they will go to the other fork with the changes.

Github/git really starts making the project truly open.

Here is a decent post about github collaboration.
http://coldfusiondarklord.com/post.cfm/git-github-coldfusion-and-open-source

[Baz]

Why should the project remain dormant if the creator is off to other things?

GitHub makes collaboration easier and more fun (I'm all for it), but it is not required to fork an OS project. If Sean disappears, the project would be dormant regardless of what versioning was used, because he's the only one with the keys - it's the fork that would be open, and that could be in any VCS.

There could even be changes that are deemed outside the FW1 scope so not incorporated in Sean's repository yet some people may want those so they will go to the other fork with the changes.

Same with adding features, it's just a fork, the VCS doesn't matter.

[Sean Corfield]

On Thu, May 13, 2010 at 1:09 PM, Mike Henke <henk...@gmail.com> wrote:
> Or lets say Sean takes a 3 month vacation and doesn't work on FW1.

That would be nice (but a sadly unlikely prospect :)

> There could even be changes that are deemed outside the FW1 scope so
> not incorporated in Sean's repository yet some people may want those
> so they will go to the other fork with the changes.

Once thing Brett and I have talked about is having satellite FW/1
extension projects that add features not deemed core. Those projects
could simply extend framework.cfc and then users' Application.cfc
could extend that wrapper. That may be a good way to incubate new
features as well - and forking the FW/1 repo to create various
satellite projects makes a lot of sense for that as well so the
wrapper and the core can continue in parallel, picking up changes from
each other as appropriate.

--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Sean Corfield]

On Thu, May 13, 2010 at 1:48 PM, Baz <b...@thinkloop.com> wrote:
> GitHub makes collaboration easier and more fun (I'm all for it), but it is
> not required to fork an OS project. If Sean disappears, the project would be
> dormant regardless of what versioning was used, because he's the only one
> with the keys - it's the fork that would be open, and that could be in any
> VCS.

Github provides direct links to all (github) forks tho' so the root
project still acts as the jump off point and if the project owner
comes back, it's easy / trivial to fold those extensions back into the
"blessed repo" so the work in the forks is much more likely to be
aggregated - which means people are more encouraged to contribute in
the first place.

That would be hard with multiple VCS systems in play.

> Same with adding features, it's just a fork, the VCS doesn't matter.

Except you'd lose the visibility of automatic links from the original
repo to those forks and the ability to view the network of changes and
to pull changes from that network into your own version.

--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Javier Julio]

On May 13, 2010, at 4:52 PM, Sean Corfield wrote:

> On Thu, May 13, 2010 at 1:09 PM, Mike Henke <henk...@gmail.com> wrote:
>> Or lets say Sean takes a 3 month vacation and doesn't work on FW1.
>
> That would be nice (but a sadly unlikely prospect :)
>
>> There could even be changes that are deemed outside the FW1 scope so
>> not incorporated in Sean's repository yet some people may want those
>> so they will go to the other fork with the changes.
>
> Once thing Brett and I have talked about is having satellite FW/1
> extension projects that add features not deemed core. Those projects
> could simply extend framework.cfc and then users' Application.cfc
> could extend that wrapper. That may be a good way to incubate new
> features as well - and forking the FW/1 repo to create various
> satellite projects makes a lot of sense for that as well so the
> wrapper and the core can continue in parallel, picking up changes from
> each other as appropriate.

Be great to see "utilities" or "plugins" show up. My concern though with the suggested approach is that it would require inheritance. So if I like one extension' feature and the other, I'd have to pick one and/or move the functionality from the other. I know it wouldn't be easy but would appreciate it if you would somehow consider how you could support this extensibility but through composition instead. If not no worries from me, happy with FW1 as is! :) Thanks.

Ciao!
Javi

[Sean Corfield]

On Thu, May 13, 2010 at 2:04 PM, Javier Julio <jjfu...@gmail.com> wrote:
> Be great to see "utilities" or "plugins" show up. My concern though with the suggested approach is that it would require inheritance. So if I like one extension' feature and the other, I'd have to pick one and/or move the functionality from the other. I know it wouldn't be easy but would appreciate it if you would somehow consider how you could support this extensibility but through composition instead. If not no worries from me, happy with FW1 as is! :) Thanks.

One of the wrapper projects Brett has in mind - which could make it
into the core at some point - is a "library" project that might lend
itself to something like that. I may also consider a convention based
plugins approach for FW/1 2.0 (I'll start working on the roadmap for
that once I get 1.1 out the door later this month - 1.2 is already
being planned).

[Mike Henke]

On May 13, 4:48 pm, Baz <b...@thinkloop.com> wrote:
> > Why should the project remain dormant if the creator is off to other
> > things?
>
> GitHub makes collaboration easier and more fun (I'm all for it), but it is
> not required to fork an OS project. If Sean disappears, the project would be
> dormant regardless of what versioning was used, because he's the only one
> with the keys - it's the fork that would be open, and that could be in any
> VCS.
>

In git/github the project would not be dormant if the creator left.
The project doesn't really belong to anyone. Everyone has a copy/clone
of the full repository (history, files, and all). Notice how the url
isn't http://github.com/fw1 , it is http://github.com/seancorfield/fw1
or http://github.com/webflint/fw1

> There could even be changes that are deemed outside the FW1 scope so not
>
> > incorporated in Sean's repository yet some people may want those so they
> > will go to the other fork with the changes.
>
> Same with adding features, it's just a fork, the VCS doesn't matter.
>

I think the VCS does matter. Let's take PayPalCFC at http://paypalcfc.riaforge.org/
in SVN.

John created it for what he needed and put it on Riaforge and SVN for
others. The Paypal API changes, how are you going to fork/branch that
for updates and let others know about it so they can use it? John
would have to grant you rights to svn or you would have to email him a
patch and hope he incorporates it.