On 17 Oct 2005, at 08:36, Mark Wieder wrote:
Richard-
Sunday, October 16, 2005, 8:27:55 PM, you wrote:
Can you tell us a bit more about projects you've worked on where
multiple team members needed to work on different controls in the
same
window at the same time?
First Scenario
The most obvious example for me is at the handler level. I have a lot
of functions that I re-use. Some of them are in libraries and some of
them in a stack - like Scripters scrap book. I often sketch them,
document them and don't quite finish them. When I reuse them, perhaps
to port them to another platform or make them more generic, or
faster, I then have to update them in the various stacks that use them.
Now this work is slower because it is not shared work. Other people
are doing exactly the same work - it is waisted duplicate effort. I
cannot share my 10 MB script library easily - so I started to port it
to CVS with a 1MB front end. Now moving over to subversion. This
would allow anyone to update a single function - speed it up, fix a bug.
When coding I can hit a function key and search though the handlers
to see documentation and if I have written something like this a few
years back - now if i could search a socially filtered repository of
all Rev developers....
Second Scenario
I need to work in an open source development community. I work with
other developers in other languages and create the rich clients for
front ends. This often works as follows - i sketch out how the call
would work locally. I call a button. This button knows nothing about
the context of Rev - it is a black box which receives data and return
data. It is a little slower than using a library or embedding the
function in the stack itself, but it has the following advantages:
1) It is more granular.
2) It is easier to understand the purpose of the object - no
need to figure out the stack and abstract the bit you want.
3) The code and documentation acts as a specification for other
developers
3) It is easy for a python / java / perl / php programmer to
replace and enhance the functionality with open source code.
Third Scenario
Skinning. Rev can be a fabulous tool for creating skins. The stack is
the skin (which can be exported to XUL / XML) and worked on by other
open source developers. For this you want to be able to drag and drop
objects (groups?) which have been refined and bug-fixed by an open
source development process. The rev "table-object" or an outline
field would be examples here - but there are many many more.
Stack based approach
is robust and works. It works because it is easy within the existing
tools for Rev. It requires minimal development. For now it works
better than the above approach - but this is the reason why so many
development efforts have not been fully integrated into the Rev
community. There are three or four tree view or calendar objects
or... out there but it is simply easier to do-it-yourself in Rev -
than find and research which stacks are out there, hack someone elses
stack, figure it out, modify it and copy it to your application. Then
you have the same problem if you want to publish your work.
Publishing Economics
It is worth publishing a stack (sometimes). But not a component or a
handler. If it were a four click process - find, download - modify -
then re-publish - all within the Rev environment then the economics
would change and more people would do this, and the chicken-and-egg
dis-economics would reverse to create of positive cycle of
incremental improvements.
Sure, but that may be missing the point a bit.
The "problem" is that stacks are monolithic, while most other
development environments use separate files: .c files, .java files,
etc. Splitting a stack into substack files helps - different
developers can work on different parts of a project that way, but a
stack is the smallest atomic unit that can be parceled out.
One problem is that as stack size grows the stack either must be split
into separate substack files to distribute the work or one developer's
work responsibility keeps growing. And splitting a stack into separate
files can require architectural changes that may have consequences
down the line. Another problem with this is that development on a
stack progresses serially (only one developer can work on a stack at a
time, then hand it off to another) versus in parallel (multiple
programmers can tackle different parts at the same time).
I've worked on java projects with 10 or so developers all crafting
pieces of a single application. Let's say someone adds a new routine
to a source file and then wants to add a reference to it to a header
file common to several source files. That developer needs to check out
the header file, make the change, and check it back in. Then when
another developer wants to make a change to the common header file
they check it out, add their change, and check it back in. Nobody can
check out the file while it's being worked on so that changes don't
overwrite each other.
Let's say there are five of us working on a project together spread
out over the world. We either have to divide the work into separate
stacks or we have to email our finished work in token-passing style.
This limits the sort of collaborative projects that can be taken on
with runrev (libraries, for example, are typically single-developer
items).
--
-Mark Wieder
[EMAIL PROTECTED]
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
