[schooltool-dev] Re: [SPAM] Re: [Cando] Re: Upcoming sprint adjustments

[Tom Hoffman]

Paul and I have talked this out, and we've reached a conclusion that I think
everyone is happy with.

We're going to use SchoolTool's REST web services to communicate with
SchoolTool's SIF agent, so SchoolTool's agent will simply act as a bridge
between the SIF zone and SchoolTool.

So the work involved is roughly:

* studying how REST views in SchoolTool were designed and work;
* bringing the existing tools up to date (a lot of what we need has already
been written for managing persons, groups, etc., but I'm sure parts of it
has been broken by subsequent changes.);
* writing a few new objects and REST views in SchoolTool to manage the
message queue via REST.
* eventually writing REST views for newer parts of SchoolTool and CanDo that
don't have them at all.

Since there are good existing models in SchoolTool for this work, and
learning REST web services is a good way to learn about the architecture of
the web in general, i think it is a good fit for the interns, and it keeps
the SIF-specific code separated from SchoolTool proper, making it less
likely we'll feel the need to completely re-write my SIF code before doing
anything new and useful.

--Tom

On 6/22/07, Paul Carduner <paulcarduner at gmail.com> wrote:
>
> After more work with SIF stuff, I am again feeling somewhat
> discouraged.  It seems like both the sifagent that Will wrote and the
> agent framework (Chesty) that Tom wrote are in serious need of
> refactoring.  For example, in the file
>
> http://codebrowse.launchpad.net/~chesty-devs/chesty/chesty-trunk/annotate=
/paul%40carduner.net-20070619041842-ke2juio8hmlx0axu?file_id=3Dsif_exceptio=
ns.py-20070329154951-he3tabno2t3clr7y-129
> we "could reduce the amount of code in there like 20 fold." (ignas)
> In order to really understand what this code is doing, we will have to
> refactor it a lot.  Before embarking on the refactoring journey, I
> tried running the chesty tests and just got back:
> WARNING:root:SIF Error cat. 1, code 2: Message is not well formed.
> WARNING:root:SIF Error cat. 3, code 5: Sender's certificate is not
> trusted.
> which is also discouraging.  The doctests also don't do a great deal
> of explaining about what is going on.
>
> Anyhow, if we end up doing SIF stuff during the sprint, we will
> probably spend the whole time refactoring the existing code - which
> isn't necessarily a bad thing as it will have to be done at some point
> or another.  But again, i'll just reiterate that the presence of Tom
> and WIll would *really* help in a refactoring effort.
>
> Does anyone else have other thoughts on this matter?  I still haven't
> started thinking about the REST/site.zcml/threading issue, as the code
> is not in the right state for "messing around".
>
> Does anyone have any other thoughts on the matter?
>
> - Paul
>
> On 6/20/07, Tom Hoffman <tom.hoffman at gmail.com> wrote:
> > On 6/19/07, Jason Straw <lists at misato.us> wrote:
> >
> > > Even if Will shows up, I still feel that ZIS and SIF are NOT the best
> > > uses of our limited time.  If we can get basic xml based import and
> > > export working that gets us to 80% of what import and export need to
> > > do.  15% for importing VA SoL and CTE comp lists and then re-exporting
> > > them to the standard format to give out to people.  and the final 5%
> is
> > > getting ZIS/SIF working, but that is NOT needed to start up in
> > > september, and could be released in a secondary package.
> >
> > The above is probably true, in my opinion.
> >
> > --Tom
> > _______________________________________________
> > CanDo mailing list
> > CanDo at schooltool.org
> > http://lists.schooltool.org/mailman/listinfo/cando
> >
> _______________________________________________
> CanDo mailing list
> CanDo at schooltool.org
> http://lists.schooltool.org/mailman/listinfo/cando
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.schooltool.org/pipermail/schooltool-dev/attachments/20070=
624/0a29dc22/attachment.htm