Complete Rewite or not ?
Ian Boston
Here is what I think, we do a complete rewrite but in a way that re-
uses appropriate code from the past.
Start with an empty container
For each area of functionality evaluate 3rd party, existing Sakai
code and new code and then
do integration, improve coverage and code quality or almost as a last
resort, write new code.
So although this might feel like a total re-write its more likely to
be replacing with 3rd party and re-factoring existing old code.
Does that scare everyone ?
Ian
John Norman
anticipate needing to evaluate and bring in? To get an idea of scale -
feel free to offer more appropriate dimensions.
I assume this might make the compatibility adapters harder?
John
Ian Boston
the build files.
I would expect to need to evaluate upto 3 major new components.
Some of the work will be in the adapters and there will be a point at
which we say that an old feature is not supported. Full backwards
binary compatibility will be expensive, and it will be cheaper to re-
work edge case code outside the kernel.
Large portions of the adapters will come from the K1 source tree.
Ian
John Norman
We are probably today at production minus 11 months.
Thomas Amsler
+1
-- Thomas
Clay
frightened of a gun pointed at me. I can't see what's out there, but
can be reassured.
My other thought is the fright that the rest of the community would
experience. For how long would we have to demonstrate production
success for people to begin to think about migrating themselves -
longer than if we worked piecemeal? Would it heighten the sense that
the K2 project team is too aggressive and shouldn't be relied upon?
Would it deepen the fracture between those committed to 2 and those
committed to 3?
~Clay
On 21 août, 11:05, "Thomas Amsler" <tpams...@ucdavis.edu> wrote:
> I think this reasonable as well as need in order to achieve our set K2 goals.
> +1
> -- Thomas
>
John Norman
> the K2 project team is too aggressive and shouldn't be relied upon?
> Would it deepen the fracture between those committed to 2 and those
> committed to 3?
I think this is an important point. Perhaps if it were possible (time
and resource wise) to demonstrate content migration and backward
compatibility progress as we go, the concerns might be alleviated
somewhat.
I'm thinking of some sort of traffic light indication of which legacy
tools are still (fully) working alongside a database/app server load
reduction chart.
That in turn implies a lot more QA-type resource than I had been
thinking about...
John
James Renfro
I think the primacy of production success as a measure of code quality
should be somewhat diminished by appropriate use of unit and
integration testing. If we can prove that the code is largely able to
do what it aims to do even before we begin QA, then we have a big
advantage over the current model. Not to say that we won't have bugs,
or that the test cases won't need to revised through a QA process, but
just that we need to get away from this mindset that once one of the
big schools has run something in production is makes it mostly "safe"
for use by others. We have plenty of critical bugs in code that is
running in production at many many schools.
Of course, with all that said, as Clay points out, it's really about
perception on the part of institutions that are making the decision.
From that point of view, it sounds like a question of how we market
what we're doing. As soon as we begin to pull this thing apart the
reality is that the reliability of the system as a whole disappears
fairly quickly, whether we begin with a blank slate and inject stuff,
or if we begin with the big mess and try to fiddle it. The difference
is mainly that beginning with a blank slate gives us better focus on
what it is we're actually doing, and provides the necessary resistance
to make us think twice about whether we really want to keep using the
in-house code, or some more reliable third-party lib.
Mike
I wonder how many modules will need both a redesign and a rewrite.
I hope it's not too many of them.
Ian Boston
the many of the modules with single off the shelf modules that
deliver the concepts.
For instance:
If we believe that a large part of Sakai is essentially a X with
customizations for education and research, and we can find a
component that delivers this functionality and passes our criteria,
then we spend time integrating that component rather than writing our
own.
One X that springs to mind is a Content Management System..... the
3rd party component might be Sling.
Another is a Component Framework for which I start to think of OSGi
like Felix
With Felix there is a concept of a Configuration manager.
So we might not be re-writing too many of the modules. The difficulty
comes with supporting the legacy environment.
Clay
started) on the question of phases of legacy functionality, on the
assumption that we can't get all of it the first time through. I know
the UX project should be leading much of this thinking, but I think
the UX project needs to take these questions as an input as well.
There needs to be a triangulation between:
1) The scope and orientation of K2
2) The outputs of the UX project
3) The respective answers of Cambridge and Georgia Tech to the
question: "What is a deployable 3.0?"
~Clay
carl...@et.gatech.edu
external offerings) is a great idea. The less we, the community, have
to manage, the more we can poor into sakai specific things. The
obvious areas to me are places of utility like email and events.
Since most if not all of Sakai is pretty well written around the basis
of interfaces, changing these pieces out shouldn't be terribly hard to
do. This says nothing for the time required to complete this
though. :-)
John Norman
We had a not-very-successful internal brainstorm yesterday on the
'social networking' demo app for Sakai 3.0. We will do some more
outside CARET with students and faculty, but the most promising idea
(from my perspective) that emerged was a small step from something
that has been kicking around CARET for a while. I'd like to get your
take on whether this would make a good intro app for GaTech and
whether you have other ideas or plans to generate other ideas:
(1) many people like presence, it seems to give them a warm feeling
that 'they are not alone' when working in a site. But when they know
there are others working in a site, they often wish to contact them.
(2) My Skype contact list is effectively a 'friends' list (actually
more like a 'colleagues' list) with an indication of who is on line
(if they agreed to share that information). (3) Skype does a nice job
of supporting chat.
So the proposal is something like the Skype contacts list as a
'startpage' gadget with the ability to initiate a 'chat' session with
any of the contacts who is shown as 'online' with Sakai, PLUS an
enhanced presence, that takes advantage of the same underlying engine
to tell you who is online in your current site and to give you the
ability to launch the same 'chat' window.
What do you think?
I don't want to get too ambitious with 3.0, I just want an app that
works well, does something useful and demonstrates that we have the
capability and are on a path to delivering academic social networking
apps.
John
Clay Fenlason
its limitations, but because of its likely use), and valuable to that
extent. One concern is going to be the ability to screen your
visibility to others, ideally with some configurable granularity (e.g.
friends only, friends+classmates, by particular class, or certain
roles only), but if that kind of "preference" is part of the picture I
think it could be a great success. The words "serendipitous
encounters" are thrown about a great deal here, even in architectural
programming of new buildings and learning centers, but we have as yet
no analogous online facilitation.
However there is a reflexive feeling that "social networking" is
something that only "the kids" will care about, that the above
features will be interpreted in that light, and I'd be anxious to also
demonstrate something of value to professors, even those (in the
majority) who won't want to participate in presence-chat capabilities.
I was still thinking that an amplified profile (hopefully with some
rudimentary linked-in way of making connections, if that's not too
challenging for our timeframe) would fill this space.
The two taken together would offer a strong start.
~Clay
--
Clay Fenlason
Director, Educational Technology
Georgia Institute of Technology
(404) 385-6644
John Norman
> something that only "the kids" will care about, that the above
> features will be interpreted in that light, and I'd be anxious to also
> demonstrate something of value to professors, even those (in the
> majority) who won't want to participate in presence-chat capabilities.
> I was still thinking that an amplified profile (hopefully with some
> rudimentary linked-in way of making connections, if that's not too
> challenging for our timeframe) would fill this space.
>
> The two taken together would offer a strong start.
I see this as a combination of social networking and content
authoring. I hope to see this idea crystallise at the Content
Authoring Summit. But you are right, I should perhaps be doing more to
articulate it now.
John
Kirk Alexander
my perception of our users - they would like a better presence (especially
since we turned it off for performance reasons!) and quick access to
a chat would be productive. It might bring up the idea of whether
that would be a private chat or a site chat and what/where it archives.
Kirk
Kirk Alexander
SmartSite Program Manager
IET-Academic Technology Services
Tel: 530-752-2133
Fax: 530-752-4655
kda...@ucdavis.edu