Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] technical details, plan, re: synthesis

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Chad Knepp <pyg@galatea.org>
  • To: pcplantdb@lists.ibiblio.org
  • Subject: Re: [pcplantdb] technical details, plan, re: synthesis
  • Date: Mon, 2 Aug 2004 21:38:09 -0500

John Howe writes:
> > So I'm just going to summarize the stuff I wrote earlier.
> >
> > o We need to settle on a platform. I would like to use Zope 2.7.2,
> > the latest stable version and python 2.3.4 (or 2.3.3). More below.
> >
> > o John H.: Can we start with your box, at least until things get
> > more settled? If so, can we use the above versions? If you are
> > short on time or don't want to mess with differing global versions,
> > I can (w/shell access) do a local install and run it nohup on a high
> > port so the group can play with it. I can also be talked into
> > different versions with convincing arguments.
>
> I was planning to have that completed by the end of this week.

Great, that's a week earlier than I expect to need. I'm assuming
these versions are ok?

> > o Zcatalog is for Zope objects. This still may be what we want, but
> > I really haven't spent much time looking at Zope itself. There is a
> > package for ZODB called IndexedCatalog
> > <http://async.com.br/projects/IndexedCatalog/> which should provide
> > the needed functionality independent of Zope. I don't know what we
> > will end up using but I do think that we have the tools in the Zope
> > package to do the job.
>
> I can add that to the install queue.

Actually don't bother just yet. I haven't needed it yet and Zcatalog
may be what we end up using. I give a way ahead heads up if we are
going to need this.

> > o ZODB does not have the built in capability to track individual
> > user edits infinitely. It has ACID style transactions with undo
> > (depending on storage type) just like any good RDBMS, but this is
> > for consistency and needs to be purged frequently or the database
> > will die of bloat... plus rollbacks can't happen on something that's
> > changed twice. In summary, unless we commit to programming a system
> > of tracking everything every user does (fairly complex), we should
> > go with the simpler method of adding an author credit to objects
> > that given authors add/modify.
>
> Or some sort of moderation system... or preserve the rollback info in
> backups, then truncate the DB.

Yeah I totally hope to have a moderation system that filters good up
and sketchy down. What I was really referring is attributing
copyright info, and I don't think it's really going to be possible to
keep track of who holds the copyright to every single word, frame, and
image in the database unless we write our own system. I also don't
think it's necessary to do so even if it was already built in.

> > Aug 2-4 Finish demo accounting/budgeting app. in ZODB w/CLI
> > Aug 5-7 Create a Zope front end for app (to learn Zope)
> > Aug 8-12 Start and finish 1 of my plan (Week 2 of Project Plan)
> > Aug 13-14 Get it running somewhere/somehow
>
> That seems on target with my schedule >;}~
>
> > > -ZOPE $(G!9(B Lawrence called me tonite and filled me in on the ZOPE
> > situation,
> > > thanks Lawrence. And thank you John H. for offering to correspond to
> > > Ibiblio about this! Have you done so? When do you think you will?
> > > Please let me know, so I can add it to the project plan.
>
> I haven't spoken with ibiblio formally yet. I would need some time to
> document a draft and pass it around for approval.

If you are into it I say go for it.

> > My take and I think John^2's is that Zope is the better choice. It
> > will probably take more time to get going with it, but with all the
> > built in tools and packages available it will probably save time in
> > the long run. Although I don't know how it will perform I'm pretty
> > confident that we can optimize performance bottlenecks as we go along.
> > We can in fact use MySQL (or another RDBMS) as the storage backend to
> > ZODB if FileStorage isn't fast enough or becomes unscaleable.
>
> Zope isn't as fast as apache, however, there are optimization/caching
> techniques to be tuned. Scaling has been talked about with ZEO ( Zope
> Enterprise Objects ).

Yeah, I'm not really worried.

> > Yes, but I often don't know what people don't understand. I would be
> > happy to eloborate on things if you ask for clarification about things
> > you don't understand.
>
> Ditto ..

--
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'




Archive powered by MHonArc 2.6.24.

Top of Page