I agree. There are much larger issues that need to be resolved before
discussing implementation details in this forum.
I think it's great that the folks discussing the experimental architecture have
identified areas where VCL can be improved and I would like to find a way for
the community to efficiently and prudently incorporate them into VCL.
I would like to understand why these ideas can't be incrementally incorporated
and tested into the current VCL codebase. I think this approach would have a
much higher chance of success, no? Was this approach considered? If so, what
were the barriers to this approach which couldn't be resolved?
It will be counterproductive if a developer has to choose one version or the
other as the basis of his or her contributions. This will result in a split
community. In addition, having 2 vastly different architectures under the VCL
project will cause significant confusion. Agree?
Regards,
Andy
Josh Thompson wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday May 17, 2009, Michael Brown wrote:
The wiki document for the experimental branch now suggests the use of a
database abstraction layer. I propose the use of an object relational
mapper to accomplish this abstraction. This has the advantage of being
extremely easy to use, less code needs to be written, therefore fewer
errors will result. The con to an object relational mapper is performence
during bulk database operations. This should not be an issue because vcl
performs no large transactions.
Does the community agree that any future major proposals should include a
database abstraction layer using an object relational mapper because of the
above advantages?
This part of the community (me) doesn't agree with any implementation details
of the so called "experimental branch" until we've had good discussion about
problems with VCL in its current form and seriously looked at how those
problems could be fixed without doing a complete rewrite. (I
put "experimental branch" in quotes because a branch implies being a
derivative work of trunk, but in this case it is a completely separate
architecture designed without the input of those that developed the existing
codebase.)
I suggest work on this "experimental branch" halt until the community can
come together on this issue instead of being fractured any further.
Josh
- --
- -------------------------------
Josh Thompson
Systems Programmer
Virtual Computing Lab (VCL)
North Carolina State University
josh_thomp...@ncsu.edu
919-515-5323
my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFKEW2TV/LQcNdtPQMRAsREAJ9bcdCZRlgqaUR410njudbKln5YRQCbBEtt
PWAY2YWVpxc1qBmhKctwR/0=
=dapR
-----END PGP SIGNATURE-----
--
Andy Kurth
Virtual Computing Lab
Office of Information Technology
North Carolina State University
andy_ku...@ncsu.edu
919.513.4090
