Etria Lists

On 11/1/06, Tim Hicks <tim at sitefusion.co.uk> wrote:
> Maurits van Rees wrote:
> > Tim Hicks, on 2006-10-31:
> >> Reinout van Rees wrote:
> >>> One thing, from the top of my head, *is* a quills problem: the
> >>> permissions to create the on-the-fly 2006/10/31-like folders. Not sure
> >>> if that's right.
> >> My recollection is that a cut-and-paste operation is performed that
> >> moves the entry from the weblog root to the new archive home.  Unless
> >> I'm mistaken, this cut/paste needs to give the user the delete
> >> permission, and so allows them to delete all other weblog entries in the
> >> weblog root.
> >>
> >> Getting rid of the cut/paste operation (by faking traversal) means we
> >> wouldn't need to grant the delete permission, which should make life
> >> marginally better for Michael, I think.
> >
> > I'm thinking about putting some time in here, but I have no idea where
> > to start.  Is there another product that fakes traversal?  A working
> > example is always useful.
>
> Quills already does this for the [weblog]/topics/* hierarchy.  See
> <http://dev.plone.org/collective/browser/Quills/trunk/traversal.py> and
> associated zcml.  I've done my best to comment it heavily and make the
> code as clear as possible.
>

There is also one or more and/or both of a bug and a qlip addressing this.

> >  The last I found on improving this part of
> > Quills is from tvon in April this year:
> >
> > http://dev.plone.org/collective/log/Quills/branches/tvon-flat-btree-weblog
> >
> > But that only removes some code and doesn't yet do anything
> > traversal-like.
> >
> >
> > Personally, I want to move my own ZMI-made Zope 2.7 blog to Quills.  I
> > would like to keep using weblog/year/month/entry-title instead of
> > weblog/archive/year/month/day/entry-title.  Maybe I'll just throw in
> > an Apache rewrite rule to redirect weblog/200x to weblog/archive/200x
> > and solve half my problem.
>
> If you implement the traversal faking, then you won't need the rewrite
> rule as you can just do it in the traversal adapter.
>

Well.. rewrite rules are fast.

I use RedirectionTool on siggraph.org so that my users can prepare
content in new.siggraph.org, rename it if necessary, and preserve the
integrity of links as old as ten or more years.  I think this probably
does some similar things to the type of behaviour we want, though I
think it is also sort of like LP and creates a referenced object for
the alias.

In any case, if there are multiple levels of folders which have each
changed names, I haven't profiled, but I presume too much python for
my taste is running.

So, I poke around periodically and find aliases of large folder
structures and put rewrites into the Apache config.  Again, I'm just
guessing, but I'm pretty sure mod_rewrite is faster than traversal.

> > For the other half of the problem: I'm thinking about monkey patching
> > createPath in WeblogArchive.py to not create the 'day' archive folder.
> > Are there better ideas?
>
> I have a much better idea :).  WeblogArchive should disappear as a
> persistent content type.  It should be constructed on the fly for each
> request, in the same manner as the Topic and AuthorTopic classes are now
> in traversal.py.  There should probably be a well-defined IWeblogArchive
> interface, though - and it may even have similar methods to the current
> persistent implementation.

Okay, so, this is wierd.  When I saw the subject of this message I
instantly had an idea, because we haven't talked about this in a
while.

When I worked on a large customer service tracking system, we had a
problem with wanting to keep track of the millions of requests,
responses, private comments between employees, etc..  The problem is
that we had a single database table which held each message, and a
single table which held all tickets.  When we had 500 open customer
requests and wanted to show a relevant listing, the system did not
perform at all reasonably, whereas it could probably handle 1000
concurrent users on 500 records if there were no other records.

Of course, this is inevitable, and not much related to Quills, but our
solution is.  We implemented a ticket archive.  Various rules, sort of
like a workflow, controlled whether or not various actors could
manipulate certain states of the issue - esp "confirm solved", which
usually required an unbroken three-step chain of interaction between
employee and customer which I won't go into here. ;d

When a ticket became confirm solved, it could no longer be interacted
with - you could refer to it in a new request, but it became archived.
 Searches and "archived views" of ticket queues would see everything,
but the equivalent of a blog's front page or RSS feed were limited to
active / recent items.

I think we could just tack on a btree called archive in the root of
Quills and, optionally, traverse into it, or even just not try to
traverse into it until we fail to find an item up-front.

For a site with 100 blogs, 200 or so posts each, but maybe only a
handful active or recent, 90-some percent of requests would typically,
for blogs like tomster.org for instance, almost never hit the archive.

Saying this outloud reminds me of something, though:

  Every time you move an object in a workflow transition, god kills a kitten.

It's true.  I wonder, however, if we could save kittens by being
closer to the container implementation than the workflow.

IArchiveContainer ? ;)

> I'm away from tomorrow morning until Monday, but would be glad to
> provide pointers for what I have been thinking/planning on this front
> after that.  Andrey Fedoseev (aka cornelius on plone.org) has a good
> grasp of how things should be done, I think.  He was talking about
> working on this a while back, but I guess he never had the time.

I'd love to hear Andrey's ideas, and to help.  Maybe I will try
cutting a branch off of 1.5 which does something like I suggest.

-- 
Justizin, Independent Interactivity Architect
ACM SIGGRAPH SysMgr, Reporter
http://www.siggraph.org/