[Zope-PTK] helping my decision

Steve Alexander steve@cat-box.net
Tue, 18 Jul 2000 11:23:50 +0100

Didier Georgieff wrote:
> Steve Alexander wrote:
> > It is usable, and it does mostly work.
> That was my main concern.
> > Just, there isn't much
> > documentation, and it probably isn't clear how to proceed with designing
> > a site that is too far different from the DemoPortal product supplied
> > with the PTK.
> OK. May be we can build an how-to in the process.
> > You haven't said what your Zope experience and Python expertise is yet.
> This portal will be for my spare time activity for putting together the net
> community around Australian rock, in an "open-source" way 'share gig, date,
> promo, etc ...) that are already in touch.
> In the 'real' life i'm engaged in a big projet for government agencies in france and
> we will use Zope for that.
> So my Zope experience is quite new (6 weeks) but Zope is so powerfull that i
> already built the shared adressbook quite easily (only DTML + ZSQL, no
> Python expertise at all).
> So i guess it will improve with the time, or at least i hope so ;-))

At present, as soon as you get past the very surface level, PTK has a
steep learning curve.
I suggest you take the time to learn Python -- it doesn't take long, and
it is a very elegant language. Try the Lutz and Ascher "Learning
Python", published by O'Reilly.

PTK is a complex Zope product. It uses some of the more advanced
features of Zope. Although the code is fairly easy to follow, there
isn't much documentation of the overall design. This makes getting into
the PTK code more difficult.

You'll find it easier if you've built Python products for Zope before.
Take a look at the Boring product, or even one of the other useful
products such as the Random products or Photo.



There's some "esoteric knowledge" involved in understanding products
like PTK, so be prepared to read lots of the mailing list archives, and
try lots of experiments on the code to see what it does. Expect to spend
time tracing through the code to see how it all hangs together.

PTK uses various parts of the ZPatterns development framework. This is
considered by many to be very esoteric and difficult to get into.


The membership portions of PTK are based on LoginManager.


You might want to spend some time looking into these.

>  > In fact, it would be really helpful if you can answer the questions I
> > put to the last person to ask a similar question on this list:
> > http://lists.zope.org/pipermail/zope-ptk/2000-June/001045.html
> OK. I'll try to.
> > What are you aiming to do?
> this portal was inspired by the feeling that all of us (Australian
> independant rock) with on-line presences are basically pissing into
> the ocean in trying to get a decent audience, and I feel that we'd all
> have a better chance of "success" if some of us formed a
> collective, and pooled our  resources.
> Idea, was for the portal to essentially be a very cool and vital
> zine, with updated news, gigs information and reports and really
> good content, with an on-line shop, MP3s of the week and all that
> kinda stuff, a really great links section, (search able) and streaming
> audio of pre-recorded 'radio shows' of new releases and
> interviews etc.
> The Portal would be the absolute first stop for anybody wanting
> info on Australian rock'n'roll.

This sounds like a job for the not-quite-written-yet PTK-Squishdot
combination. Perhaps Chris Withers can chime in here :-)

> > How many users?
> 10 millions of readers, but may be less than 20/30 "managers".

Let's divide the users into three types:

  Readers:  only read, never add content or comment on content
  Members:  add content and comment on content
  Managers: vet some content before it is published, manage the site

How many of each type of use do you need to support?

Zope and PTK (using LoginManager) can handle loads and loads of users.
There are some issues with PTK's arrangement of user's home folders that
can cause a problem with many registered users on a PTK site. There are
ways around this, and it will be fixed in a future PTK release. You
might find you have to hack PTK internals to fix it, though.

> > Do your users take on different roles?
> Yes, but only for the "managers" with differents roles according to the section
> they have the managing role.
> > When do you aim to deliver a working version?
> ASAP. But we all have already some web site working, mainly by hand.
> Content is already there.

If you're going to use PTK for this, you should be prepared to keep up
with changing software. Although we'll try to keep new releases
compatible with old data, inevitably there will be problems. Learn about
external methods, and how you can update objects as needed.

> I guess the first working version should have the news/gig announce/new record
> announces/Listening section working.
> And the rest will be added quietly while switching from the ancient web sites.

I'm not sure what the Listening Section does, so I can't comment on
If you're storing lots of MP3s, you should consider using LocalFS and
Apache, so you can store them on the filesystem rather than in the ZODB.

You can easily have news, gig announcements and record announcements
with the current PTK and minimal labour.

> > How critical is the timing of the project?
> No real pressure because it's an "open" and cooperative portal but the decision
> is NOW (technical architecture, design, hosting, switching, ...).

Your requirements are very much aligned with what the PTK is about. That
very much suggests you'd do well going with the PTK for this.

Unfortunately, the PTK is young, ill documented and a bit hard to get
into. Only you can decide whether that makes it too risky.

You can always ask on the Zope-PTK list for free help. There's probably
also knowledgeable folk around who would spend paid time consulting on a
PTK project. You also have the source. So you have several options.

> > What is your project team's background in developing software in Python?
> at the moment the team is greatly composed by me ;-)
> No python knowledge but other languages, so i can take the path.
> > What is your project team's background in developing software usingZope?
> Quite new, but now involved professionally so should go better in a while. (if not
> i'll be fired ;-))
> > How do you expect the system's requirements to evolve over the nextthree
> months?
> I don't understand. Which system ? PTK or my portal ?

Your system.

> I'm planning to add the missing functions i need as long as i know (and
> understand) how to be in the PTK framework.
> The main concern is to be able to develop now and NOT to have to rebuild from
> scratch if major things changes. Small changes are unevitables and will be
> managed.

You should not have to rebuild from scratch. You might have to do some
work keeping your data up to date with changes in the PTK.

> > Do you need to interface with external systems for authentication?
> Normally no. (see up there)
> > Do you need to interface with databases other than the ZODB?
> May be, but not for the first versions, i guess the functions can be handle in
> ZODB nicely.

Other than the MP3/large files issue, I think it can all live in ZODB.
If you have very large membership, you might want to set that up in an
external RDBMS. 

> Just an addition.
> For my "professional" project, the responses are :
> > Do you need to interface with external systems for authentication? 
> Yes. MySQL tables thru ZSQL. 
> Tables used and already designed for an application 
> that shared corporated "four 11" between 40 govnmt 
> agencies.

Look into LoginManager for that.

In summary: I think PTK is a good match for what you want. However,
there are substantial risks because PTK is new, and evolving, and you're
not very experienced with Zope and Python.

Hope that helps.

Steve Alexander
Software Engineer
Cat-Box limited