Re: [Zope-dev] Zope3 on Google AppEngine

2008-06-01 Thread Kapil Thangavelu
perhaps too late to help with the sprints, but i got zope3 running on
app engine last week http://zope3.appspot.com and
http://zope3.appspot.com/tests, and blogged about to
http://blog.kapilt.com

most of zope.app isn't useable due to persistence or containment and
security proxies, but page templates and the publisher work. some
fairly minor but pervasive changes (removing some deprecations/bbb
code) were needed, and to have space (1000 file limit) to actually
develop an application requires stripping the eggs of text and tests.
i ended up using the publisher support in zope.publisher (3.5.1+)
instead of ore.wsgiapp or lovely.nozodb as it presents a much more
minimal dependency set.

i'd like to see if i can get some form machinery going underneat the
1000 file limit, and publish a starter tarball for folks interested.

i'm uncertain long term what's viable, as their were a number of
changes needed, and how best to maintain them. if their suitable for
upstream into the zope repository, or just done again for separate
releases as gae variant of z3.

cheers,

kapil

On 5/22/08, Jodok Batlogg [EMAIL PROTECTED] wrote:
 Hi,

  Next week Lovely will be sprinting in New York/San Francisco to get the
 Zope3 framework and the first applications running on Google AppEngine.
 You're welcome to join us.
  Google AppEngine is a perfect match to the transition we at Lovely Systems
 made during the last 12 month in stealth mode.
  We're using heavily WSGI and are replacing ZODB within most of our
 applications.
  Tomorrow we're leaving to New York visiting our friend reco. dobee and I
 will be working on getting the component architecture running on AppEngine.
  Later next week we'll fly to San Francisco to attend Google I/O and get
 even more insight to the technology.
  We're open to release lovely.nozodb and the related components in near
 future, as usual - just some polishing missing…
  Please drop me a note ([EMAIL PROTECTED], batlogg on skype/AIM) or
 give me a call (+43 664 9636963) if you want to join us.

  jodok
  --
  Lovely Systems, Partner

  phone: +43 5572 908060, fax: +43 5572 908060-77
  Schmelzhütterstraße 26a, 6850 Dornbirn, Austria
  _
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Component registry simplification leftovers

2008-06-01 Thread Kapil Thangavelu
i was setting up a z3 app with a pau utility, and noticed some strange
behavior, which tracked down to, the PluggableAuthentication's
getPrincipal method, source below.

def getPrincipal(self, id):
if not id.startswith(self.prefix):
next = queryNextUtility(self, IAuthentication)
if next is None:
raise PrincipalLookupError(id)
return next.getPrincipal(id)
id = id[len(self.prefix):]
for name, authplugin in self.getAuthenticatorPlugins():
info = authplugin.principalInfo(id)
if info is None:
continue
info.credentialsPlugin = None
info.authenticatorPlugin = authplugin
principal = interfaces.IFoundPrincipalFactory(info)(self)
principal.id = self.prefix + info.id
return principal
next = queryNextUtility(self, IAuthentication)
if next is not None:
return next.getPrincipal(self.prefix + id)
raise PrincipalLookupError(id)

i had setup a local site with a pau with a prefix and an ldap auth,
lookups for common groups like zope.EveryBody, zope.Authenticated,
would in turn call queryNextUtility. however instead of returning the
global site manager's principal registry, it would fail in the utility
lookup.

digging deeper, the queryNextUtility call is passing in a context of
the authentication utility itself, which looks like a throwback to the
older IComponentLookup adaptation, instead of the current thread local
site manager with bases, thats currently used. When the auth utility
is passed to queryNextUtility, the default site manager whose bases
are queried is the global site manager, resulting in no utility found.
Where as passing context none, gives the expected behavior, of looking
up the current local site's bases for the auth utility in the global
site manager.

it appears to me, that this is a throwback/missed refactoring from
jim's merge of the component registry refactoring.. can anyone confirm
the analysis and the bug?

this pattern is present in multiple places in pluggable auth utility
implementation, and also,
zope.app.security/zope/app/security/vocabulary.py:219

cheers,

kapil
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.

2008-04-19 Thread Kapil Thangavelu
On Sat, Apr 19, 2008 at 8:11 AM, Martijn Faassen [EMAIL PROTECTED]
wrote:

 Jim Fulton wrote:
 [snip]

  can you elaborate with a few more sentences
   why?
  
 
  I could, but I'd rather not.  I suggest reading:
 
   http://mjg59.livejournal.com/84586.html
 
  if you haven't already.
 

 I concur with Jim - let's avoid ExtJS as their license is not clear.

 When I studied th details of the ExtJS license, I came away with the same
 conclusions as this blogger before I read that blog. I was interested in the
 discussions surrounding it because of this; I'd already decided not to use
 it. Don't think that since they mention it's LGPL it actually *is* LGPL -
 it's clear their intent is different.

 ExtJS is not *actually* licensed under the LGPL. The LGPL appears nowhere
 in their source code; it has its own license. They seem to think they can
 invoke the terms of the LGPL and then restrict them further to forbid use in
 a larger framework.

 See also my comment here:

 http://reddit.com/r/reddit.com/info/6enr7/comments/



i found this jack's (extjs author) comments on this thread illuminating
(more so the original livejournal link).. nutshell is as you said, that
extjs is not released under the LGPL. All appearances, claims, and links on
their site not withstanding...

http://extjs.com/forum/showthread.php?t=27592highlight=license

matt assay did a blog post which sums my opinion of their licensing..

http://www.cnet.com/8301-13505_1-9878693-16.html

too bad, its a great toolkit.

cheers,

-kapil
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: straighting out the SQLAlchemy integration mess

2008-04-10 Thread Kapil Thangavelu
On Thu, Apr 10, 2008 at 1:31 PM, Andreas Jung [EMAIL PROTECTED] wrote:



 --On 10. April 2008 19:10:49 +0200 Brian Sutherland 
 [EMAIL PROTECTED] wrote:



  Just adding my few requirements:
 - Integration into the component architecture in such a way that I
   can specify the db connection parameters in ZCML and that database
   reflection still works. I want to be able to get a handle on
  SQLAlchemy   things by calling getUtility.
 

 Please *NO* database specific configurations within ZCML. We're running
 applications in up three or four different environments and I don't want to
 maintain instance specific configurations within ZCML. Either we pass
 such informations through environment variables or the database
 connections parameters are read from a configuration within the instance
 configuration.



i still don't see the harm having zcml db conf  in a base package, if you
don't have to use it to setup your particular deployment's connections.

-kapil
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] straighting out the SQLAlchemy integration mess

2008-04-09 Thread Kapil Thangavelu
On Tue, Apr 8, 2008 at 5:54 PM, Martijn Faassen [EMAIL PROTECTED]
wrote:

 Hi there,

 [I originally picked this up on a thread on zope3-users, but this deserves
 its own thread here]

 There are at least three approaches to SQLAlchemy integration with Zope:

 * z3c.zalchemy (Christian Theune)

 * z3c.sqlalchemy (Andreas Jung)

 * collective.lead (Laurence Rowe)

 All of these are in various states of brokenness. z3c.zalchemy doesn't
 work with SQLAlchemy trunk. collective.lead works with it, but only if you
 check out a particular branch, and not with sqlite. Quite possibly
 z3c.sqlalchemy has a release that actually works. One out of three is not
 bad... :)

 Then there's also mentions about WSGI-based integration, and I think in
 Plone, Alchemist probably also does its own integration...


ore.alchemist works with sqlalchemy 0.4 series, and i've been doing z3 rdb
only apps with it over the last year.  i'm biased, but i think it has the
easiest api integration of any of the others..

 from ore.alchemist import Session

thats it.. all you need for transaction integration with sa, no magic
utilities to setup mappers, or tables.

the rest is as documented by sqlalchemy. it goes on to provide additional
zcml syntax for defining connections and binding them to sqlalchemy
metadata, but usage is optional.

as for the wsgi based integration, to get zope3 without the zodb, i use
ore.wsgiapp which just defines a utility which is the traversal root. i'd
like to refactor it to use the new zope.publisher paste support directly, as
it currently it includes a bunch of boiler plate from a generated


 There must be a reason for this proliferation of approaches. What is it?
  We all get along, don't we? I know that the various packages are taking
 code and approaches from each other too.


we all had different needs, some wanted to play in z2 land where broken egg
requires are the name of the game, some in z3 land... some were just the
first to arrive. i wanted and implemented higher level semantics to generate
interfaces from tables, and vice versa, and automatically generate forms
etc.




 Can't we work together more and at least come up with *one* package that
 works? Perhaps factor out some low-level commonality than then all share?
 Criticize one of the other packages until you're satisfied, and then retire
 your own package perhaps? I know the various packages add on their own
 approaches to configuration and might offer higher level container
 approaches. Those could be in different packages, sharing a foundation.

 In the end, I hope we will end up with just *one* integration layer, that
 is released, that works with Zope 2 and Zope 3 and a recent release of
 SQLAlchemy, that is documented, and that people know about. We can then
 offer packages on top of this that offer extra features.


that sound good, i'd like to see a common base layer, providing transaction
support, simple containers.

cheers,

kapil
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: straighting out the SQLAlchemy integration mess

2008-04-09 Thread Kapil Thangavelu
On Wed, Apr 9, 2008 at 9:15 AM, Laurence Rowe [EMAIL PROTECTED] wrote:

 The transaction manager here:


 http://svn.plone.org/svn/collective/collective.lead/branches/elro-tpc/collective/lead/tx.py

 Has support for TPC and savepoints. It is tested and works. The only issue
 with sqlite is that the default in the branch is to use two-phase commit and
 sqlite does not support this. Apart from that the module is completely self
 contained.


 The public interfaces to it is the two functions at the bottom,
 join_transaction and dirty_session. The idea of the dirty_session stuff is
 to prevent unnecessary commits when data is only read. Session writes
  trigger the 'dirtying' automatically with a SessionExtension:



 http://svn.plone.org/svn/collective/collective.lead/branches/elro-tpc/collective/lead/database.py

 The downside of this approach is that the when you interact with the
 connection directly to modify data you must call dirty_session yourself. If
 this is a problem for you then you may set up the transaction to be in the
 dirty state initially.

 Thread based session management is used (scoped_session). There is fairly
 extensive testing of this and the transaction support here:


 http://svn.plone.org/svn/collective/collective.lead/branches/elro-tpc/collective/lead/tests.py

 I think it would be worth factoring out the threaded session support as
 well as the transactions.


+1, the collective.lead transaction support looks nice.




 @Christian:

 I'm not quite sure what you mean by:

 - Database triggers as events

 I don't see how you could reasonably get a database trigger on the db
 server to instantiate a zope event on the db client. Perhaps the database
 could be persuaded to make a request to a URL on a trigger, but this seems a
 bit slow and maybe not a great solution.

 - Making SA 0.4 work with security proxies

 I don't know anything about security proxies in zope 3, but surely this is
 just a matter of what the base class is / the container implementation? I
 don't see why an SQL Alchemy mapped object would be any different to any
 other object.


its more to do with the fact that proxies are restrictive by default, and
the sa api likes to monkey attributes on instances. christian kicked off
some nice work with the sa developers at pycon to get this behavior
configurable in sa ( instrumentation branch) which obviate the need to
remove the proxies before calling into sa apis on an object.




 @Martin:

 Should one phase commit be set as the default to make it easier to work
 with sqlite (and mssql)? Probably yes.

 Should the default be for sessions to start out `active` or `dirty`? If
 they start out `dirty` then existing 1.0 code should work as before.

 It'll probably be next week before I manage to get this tidied up and
 merged back to trunk.

 @everyone:

 If we can all agree to use the same basic session and transaction
 management then we should probably push for it to be included as a
 sqlalchemy extension module.


sounds good, or failing that (due to additional dependencies), a common base
package.

cheers,

kapil
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: Exposing a the simple publisher (Re: [Zope-dev] Re: Reducing dependencies of zope.publisher)

2008-03-26 Thread Kapil Thangavelu
On Tue, Mar 25, 2008 at 9:19 AM, Jim Fulton [EMAIL PROTECTED] wrote:


 On Mar 25, 2008, at 5:25 AM, Martijn Faassen wrote:

  Security proxies: this topic may not be directly publisher related,

 It's not.

  but maybe it is.

 Nope. :)

  Somewhere quite low in the request handling of Zope 3 a security
  proxy is introduced around the objects being traversed.

 This is done by the default Zope 3 publication object,
 zope.app.publication.zopepublication.ZopePublication.


i've deployed apps with a custom zopepublication in part to bypass security
proxies, and its unfortunately not the only place that injects security
proxies. the more difficult injection point to avoid is the one in

zope/app/pagetemplate/engine.zopeTraverser




  Grok doesn't want security proxies, so rips them off again in a
  custom publisher. It'd be nice if there were a hook point that would
  enable us not introducing this proxy in the first place.


 There always has been, as I've mentioned many times. The same hook
 point allows use of Zope 3 without ZODB.  These policies are provided
 by the publication object.  It's a shame that the convoluted setup
 system made this so inaccessible.


 My hope is that zope.publisher.paste makes it *much* easier to use a
 different publications and thus a different set of policies. (I plan
 to update zc.zope3recipes to provide an instance recipe pased on paste.)

 I'm 99% sure that most or all of the simplicity to want has already
 been there for a long time or is there now with the simpler setup
 framework in zope.publisher.paste.



 Note that my proposal wasn't to simplify the publisher.  I think it
 already is pretty simple and I hope the recent zope.publisher.paste
 work exposes the simplicity by stripping off layers of overly complex
 setup.  My proposal was simply to extract some core functionality in a
 way that greatly reduces dependencies.  I don't expect this stripped
 down version to be of interest to most of the zope community.  I do
 think it might be useful to people with much more limited needs.  I
 didn't the proposal because I thought it would be of general interest,
 but to ask permission.  I want to do this refactoring, to avoid a (yet
 another) fork of the publisher. I should have made this clearer.



this all sounds really nice. i've been doing rdb apps with zope with custom
publications.. but getting the initial setup right for wsgi involved some
dead chickens to reimplementing the the wsgi application setup that had zodb
bits setup and event firing hardcoded.

looking over the new zope.publisher.paste code, it looks like it also pushes
the responsibility for application setup to the publication factory.. ie.
zcml loading, application startup events.

+1

cheers,

kapil
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope 3 without ZODB

2008-02-12 Thread Kapil Thangavelu
try ore.wsgiapp in pypi, you provide a root utility and traversal begins
from there, the zodb is never opened. the default publication looks up the
app root via utility and traversal continues from there. i've been using it
successfully for a number of relational apps without the zodb.
hth,

kapil

On Jan 15, 2008 1:27 PM, Jim Washington [EMAIL PROTECTED] wrote:

 David Pratt wrote:
  Hi Chris. I was scanning the lists looking for posts similar to this.
  Were you successful in getting something like this to work? Anyone
  else document anything like this?
 
  I wrote a different main.py at some point about a year or so ago so
  both twisted clients and servers to could be started up using schemas
  for zconfig but am looking at possibilities without and with other non
  ZODB backends. I see Philip provided some clues for a mixin that could
  be used to glue the publisher's traversal mechanism together with an
  alternative storage.  Many thanks.
 
  Regards,
  David
 I, too, am interested in this.

 I'm taking a hard look at Sedna, http://modis.ispras.ru/sedna/ , a
 multi-user XML database, which seems to fit my brain and my current
 xml-ish bent a bit better than ZODB or rdb.

 The python modules advertised don't work reliably enough for me, though
 I have hacked together a protocol module that works to my satisfaction
 so far.  If anyone wants to play with it, I'll throw it into the zif
 collective on Sourceforge.  I'm thinking it may be possible to do an
 elementtree (with full XPath!) interface to Sedna.

 Anyway, Chris, any pointers on interfaces and configuration would be
 very much appreciated.

 -Jim Washington




 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Killer App for ZClasses

2007-04-25 Thread Kapil Thangavelu

On Wed, 25 Apr 2007 16:13:43 -0400, Andreas Jung [EMAIL PROTECTED] wrote:




--On 25. April 2007 21:51:24 +0200 Dieter Maurer [EMAIL PROTECTED]
wrote:




In your (stripped away) example, I saw lots of magic (e.g.  
grok.context,

grok.name, @grok.action).


But readable and comprehensible magic...but I would not call that magic.




For me (several years back), Zope's TTW capabilities have been
a major reason why I got interested in Zope.


Interesting ...



i too got seduced by the zmi, before i realized it had the grip of an iron  
maiden.



Had I then seen the nasty ZCML files so much liked in Zope 3, I
would probably have turned away very rapidly.


ZCML is a pain in the ***...that's why Grok is attractive for
writing Z3 apps and attracting more people to Z3.



amen.. part of the appeal of grok, for me at least, is that its basically  
a meta-framework for constructing your own domain specific languages.






Is this so much harder than ZClasses? I believe no


As someone who used ZClasses intensively, I believe yes.


As so often, I disagree and must second Philipp.


i'd agree with andreas but for one thing, restarting the app server for  
minor code changes is painful.. akin to going from python back to compiled  
languages. for all their deployment/development best practice faults,  
zclasses offered quick iteration.


-kapil


___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Product doesn't work in zope 2.7 that was working in 2.6

2004-10-16 Thread Kapil Thangavelu
this has nothing to do with zope.

the problem is due to the severe monkey patching, use of eval, and other
bad practices in this product.

its monkey patched attributes into zcatalog and in doing so altered the
modules namespace, replacing the id function with a string.

which leads to the error, as zcatalog uses the builtin python function
id to determine the current transaction and manage subtransaction
thresholds for mass indexing.

-kapil


On Wed, 2004-10-13 at 20:54 +0530, Nagarjuna G. wrote:
 On Wed, Oct 13, 2004 at 12:56:50PM +0200, Andreas Jung wrote:
  Best to contact the authors of the corresponding directly.
 
 Well, the author (undersigned) doesn't know what to do.  The question
 was not from the users of the application but from the developers. 
 
 This product works perfectly till 2.6.3, starting from 2.6.4 and
 upwards this problem appears.  Looking at the release notes did not
 indicate any changes to the API of catalogue product.
 
 Nagarjuna
 
  --On Mittwoch, 13. Oktober 2004 16:32 Uhr +0530 MET 2004-2005 
  [EMAIL PROTECTED] wrote:
  
  Can anybody please help me,
  Our product Named GNOWSYS is working perfectly in zope 2.6
  but when ported to zope 2.7 it does'nt get instantiated.
  I guess the way we are cataloging our Objects is not correct
  The Traceback of the error that occurs when we try to instantiate our
  product is as follows
  
  Exception Type  TypeError
  Exception Value 'str' object is not callable
  
  Traceback (innermost last):
  
  * Module ZPublisher.Publish, line 101, in publish
  * Module ZPublisher.mapply, line 88, in mapply
  * Module ZPublisher.Publish, line 39, in call_object
  * Module Products.GNOWSYS06.GNOWSYS, line 475, in addGNOWSYS
  * Module Products.ZCatalog.CatalogAwareness, line 116, in index_object
  * Module Products.ZCatalog.ZCatalog, line 537, in catalog_object
  
  TypeError: 'str' object is not callable
  
  is there a specific way for cataloging Objects in zope 2.7 please let us
  know ___
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )
 


signature.asc
Description: This is a digitally signed message part
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: inconsistent mimetype assignment for uploaded files

2004-10-11 Thread Kapil Thangavelu

i believe you were referring to
http://freedesktop.org/Software/shared-mime-info

spec 
http://freedesktop.org/Standards/shared-mime-info-spec

its a system wide shared mime database for use by applications (ie. both
gnome and kde). apparently no python bindings.

-kapil


On Tue, 2004-10-05 at 10:42 -0400, Fred Drake wrote:
 ?
  
 I think there's a library from the Gnome desktop project for this
 (basically providing something like the Unix file command), but I
 don't know if there's a Python wrapper for the library, or an
 all-Python re-implementation.
 
 
   -Fred
 


signature.asc
Description: This is a digitally signed message part
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: [Zope3-dev] RE: [ZODB-Dev] Subversion repository layout

2004-04-27 Thread Kapil Thangavelu
On Tue, 2004-04-27 at 10:27, Martijn Faassen wrote:
 Kapil Thangavelu wrote:
 
  sigh.. debating over what the book says isn't very productive.  my
  conclusions at the end of my previous email, namely that what this
  layout will accomplish for the zopeorg repository in terms of avoiding
  renames of checkouts will likely be fairly limited in pratice, still win
  me out against deviating from the standard layouts.
 
 I tried to understand this sentence a few, but I don't get it yet.
 
 So, are you saying you think we *shouldn't* use a custom layout and thus 
 stick with the 'default' svn layout, or are you saying you think we 
 should deviate from the default svn layout?

i'm saying we should probably stick with the default layout. why?
because the primary benefit of the alternative layout is to avoid having
to do a rename while checking out the trunk of a project, on checking
out from branches or tags, this is required anyways. and in my
experience most of the checkouts will likely be on release branches, and
tags anyways. iotw. its of little benefit considering the disadvantages
of moving from the default layout.

cheers,

-kapil


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] RE: [ZODB-Dev] Subversion repository layout

2004-04-26 Thread Kapil Thangavelu
On Mon, 2004-04-26 at 15:48, Tim Peters wrote:
 [Jim]
  The standard subversion repository layout is by project:
 
 proj1
  /trunk
  /branches
   /br1
   /br2
   ...
  /tags
   /tag1
   /tag2
   ...
 
 ...
 
  With this layout, when you want to checkout the main development
  branch (aka head) of ZODB, you do:
 
 svn co svn+ssh://svn.zope.org/repos/ZODB/trunk ZODB
 
  That is, you need to include /trunk at the end and provide ZODB
  as the name of the output directory so as not to get a directory named
  trunk.  If you forget the /trunk, you'll get a checkout that
  includes copies of all of the various tags and branches, which could
  be huge.
 
  I suggest, instead to use the following layout:
 
 ...
 
  Thoughts?
 
 I read some subversion docs over the weekend, and so am sufficiently
 prepared to live with the oddities of a standard subversion layout.  I
 think that if you make a non-standard layout, then everyone coming to, or
 going from, Zope from/to other subversion projects will be forever tripping
 over the uniqueness of Zope's setup.
 
 IOW, the existing subversion docs cover the standard layout quite well.
 If we do something unique, I'm afraid it becomes another piece of folklore
 that will be impossible to guess and difficult to find out about.


i like the layouts jim's presented (specifically #2 of 3), i think when
considering the subversion docs, the important distinctions are made
between the directories used for branches and tags, as long as that
information is clearly communicated the semantics are exactly the same.
the subversion docs themselves outline multiple repository structures
(for example the single project layout), although they do recommend a
standard structure, the docs go through great lengths to convey a
semantic understanding of subversion as a versioned filesystem, not a
magic functional notion as is common with cvs.  i honestly dont think
anyone coming from/to a subversion system will have problems as long as
the location of the trunk, tags, and branches directories for a project
are clearly identifiable.

quoting the svn docs.

Lay out your repository in whatever way you see fit. Subversion does not
expect or enforce a layout schemain its eyes, a directory is a
directory is a directory. Ultimately, you should choose the repository
arrangement that meets the needs of the people who work on the projects
that live there.


in the existing zopeorg cvs repository, most of the existing projects
are python packages, multiples of which must be stitched together to
make a working dev environment, using jim's layout avoids alot of
needless renaming.

on the flipside, it only avoids the renaming in the case of using the
trunk, and while they are the only things being converted at the moment,
from my experience most of the checkouts from zopeorg have been on
release branches, afaik, and i believe jim wanted to continue with
existing structure such that most of the toplevel projects are not
python packages. so the benefits/comparative advantage aren't that
strong in this case in terms of breaking with the common expectation of
repository layout.

two cents,

-kapil



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] RE: [ZODB-Dev] Subversion repository layout

2004-04-26 Thread Kapil Thangavelu
On Mon, 2004-04-26 at 22:30, Tim Peters wrote:
 [Kapil Thangavelu]
  ...
  I like the layouts Jim's presented (specifically #2 of 3), i think when
  considering the subversion docs, the important distinctions are made
  between the directories used for branches and tags, as long as that
  information is clearly communicated the semantics are exactly the same.
  the subversion docs themselves outline multiple repository structures
  (for example the single project layout),
 
 Sorry, I haven't seen that.  The Choosing a Repository Layout section does
 talk about many ways to organize repositories, like multiple repositories vs
 one, and putting all projects in a repository at top level vs grouping them
 into related subtrees.  But in all these cases, the only structure for a
 project they discuss or illustrate has project/trunk, project/branches, and
 project/tags structure.

there are numerous references throughout the docs to alternative
repository structures, like having one with

/trunk/projectname
http://svnbook.red-bean.com/svnbook/ch03s06.html

or several examples w/ pics without trunk, tag, branches at all, 
http://svnbook.red-bean.com/svnbook/ch02s03.html

but regardless its true that the vast majority of the examples assume
the 
/projectname/trunk
/branches

setup. 

 
  although they do recommend a standard structure, the docs go through
  great lengths to convey a semantic understanding of subversion as a
  versioned filesystem, not a magic functional notion as is common with
  cvs.  i honestly dont think anyone coming from/to a subversion system
  will have problems as long as the location of the trunk, tags, and
  branches directories for a project are clearly identifiable.
 
 I haven't used svn, and I'm more concerned about people like me wink:  the
 docs assume a specific project (not repository) layout throughout.  I'm not
 interested in svn for its own sake, it's just something I'll need to do my
 job.  The closer the docs match the system I have to work with, the easier
 it will be to get started.

imo, the docs dont assume one layout, they have mixed examples, with a
majority of them given with suggested layout, reading past the
copy/paste code though and i think it tries to make clear numerous times
that its not about the layout its about the semantics and policy
assigned to locations.

for example here's a quote on creating branches


Creating a branch is very simpleyou make a copy of the project in the
repository using the svn copy command. Subversion is not only able to
copy single files, but whole directories as well. In this case, you want
to make a copy of the /calc/trunk directory. Where should the new copy
live? Wherever you wishit's a matter of project policy. Let's say that
your team has a policy of creating branches in the /calc/branches area
of the repository, and you want to name your branch my-calc-branch.
You'll want to create a new directory, /calc/branches/my-calc-branch,
which begins its life as a copy of /calc/trunk. 




 
 I can't say Jim's suggestions are bad, or good -- I can't judge them since I
 haven't used svn (you?).  Going against the recommendation of the people who
 designed and coded the system seems a dubious step on the face of it,
 though.

i've been using svn for almost 2yrs, for client projects the last year,
and i'm about to convert over plone and the sf.net collective project
(~150 Products) and around 200 committers over to svn. i think jim's
proposed layout could be very helpful there, as typically people will be
using unfamiliar gui clients (like tortoisesvn) and will be checking out
the head of the products and nitting them together to create a working
zope instance/dev enviornment, in which case avoiding having to fillin
an extra dialog might be nice and pratical. but i'm going to try and
solicit feedback on those project lists.


 
  quoting the svn docs.
  
  Lay out your repository in whatever way you see fit. Subversion does not
  expect or enforce a layout schema-in its eyes, a directory is a
  directory is a directory. Ultimately, you should choose the repository
  arrangement that meets the needs of the people who work on the projects
  that live there.
  
 
 That's at the end of the Choosing a Repository Layout section.  As above,
 that section discusses and shows nothing but the standard per-project
 layout; the layout choices they do discuss in that section are the ones
 mentioned above (how to organize projects in relation to each other, and in
 relation to repositories).
 

it does shows another layout in the choosing repository layout scheme
section, namely the single project etc, which you could say jim's layout
is adapted from.. ie.
/trunk
/branches
/tags

sigh.. debating over what the book says isn't very productive.  my
conclusions at the end of my previous email, namely that what this
layout will accomplish for the zopeorg repository in terms of avoiding
renames of checkouts will likely be fairly limited

Re: [Zope-dev] order of transaction aborts

2004-04-20 Thread Kapil Thangavelu
shared/dc/zrdb/tm does not hijack the transaction mechanism it
integrates with it.

you should coalesce txn integration for your objects into a single txn
integrator so you needn't depend on transaction message/jar ordering.

-kapil

On Tue, 2004-04-20 at 11:35, [EMAIL PROTECTED] wrote:
 Is there any way to influence the order of transaction aborts when you
 hijack the transaction mechanism in a similar way as
 Shared/DC/ZRDB/TM.py does? I have Folder and File like classes which
 make changes on the file system as a part of their operation. When
 within a transaction I make multiple changes to these objects and the
 transaction is aborted, I have to do some cleanup in reverse order as
 these operations were executed. AFAIK, the p_jar.abort() calls are made
 in the same order as the objects were registered in the transaction.
 
 Regards,
 Sandor
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )
 


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

2004-04-19 Thread Kapil Thangavelu
On Mon, 2004-04-19 at 13:33, Shane Hathaway wrote:
 On Sun, 18 Apr 2004, Kapil Thangavelu wrote:

  should we move this discussion to an ape specific mailing list?
 
 I'm happy with zope-dev and zodb-dev, but if there's a good reason to make 
 a new list, that's fine.
 

its a knowledge discovery issue, there's a lot of useful info ape info
floating around on diseparate mailing lists which makes it hard to get a
hold of, having a single mailing focused on ape would make it much
easier for folks to get up to speed and see all the cool stuff that can
be done and that people are doing with ape ;-)

cheers,

-kapil



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

2004-04-18 Thread Kapil Thangavelu
On Wed, 2004-04-14 at 10:04, [EMAIL PROTECTED] wrote:
 Kapil,
 
 Right now, the svn transactions are entirely contained within a single
 fileops operation: for example a mkdir connects to a transaction root,
 performs the necessary operations, and commits, all in one shot.
 

ok, thats what about what i expected. not ideal but it works.

 Last night I took some more time to try and learn more about Ape's
 functionning (Where events come from, which interfaces are used for what,
 and TPC), so I'm starting to understand more ...
 
 The more I learn, the more I think closer integration between SVN txn's and
 Ape's TPC would be a good place to start before looking at adding features
 like history support and so on: defining a model for what happens in svn for
 each TPC related call (connect, vote, finish), and then as Shane had said,
 look at IFSReader/IFSWriter (Which I now call
 ISubversionReader/ISubversionWriter :P) to match.

part of the reason i never used ape as a means for svn integration was
was that this imo, mix of high level application operations with zodb
storage level operations never seemed a proper fit as it required
bypassing the storage interface for richer semantic operations. ie i see
reverting a revision, tagging a content tree, or diffing mulitiple
revisions as application operations. still, there have been the some
compelling ideas here about using zodb/ape as an interface.

 
 Right now the fs implementation stores script commands that are cummulated
 upon connect() (I think?), validated as best as possible upon vote() and run
 upon finish().  I don't see why this couldn't be adapted to SVN txn's ...
 connect() = start a txn, vote() = validation (what this entails needs to be
 defined, could involve delta operations, revision number matching, etc ...
 ?), finish() = commit the svn txn.
 

not exactly, you just start a txn, do whatever work, and commit in vote.
see my previous message outlining txn integration difficulties, and why
this is not ideal but currently the best option.

 Because we're within an svn transaction, there would be no need for fs style
 script command accumulation however, which is nice.
 

sure.

should we move this discussion to an ape specific mailing list?

-kapil



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

2004-04-18 Thread Kapil Thangavelu
its (cmfsvnbrowser) not what your looking for, if you want a versioning
system integrated with plone (as i recall your original request) i still
think working with zope version control (as i suggested earlier) is more
applicable in the short term.. as an integrated example of doing object
version control entirely in zope see,

http://occams.objectrealms.net

-kapil

On Thu, 2004-04-15 at 06:36, Arthur Chan Chi Chuen wrote:
 cool, let me try the cmfsvnbrowser first
 
 thanks. =)
 
 Arthur
 On Wed, 14 Apr 2004 10:35:14 -0400, Jean-Francois.Doyon wrote
  Well there you go, perfect :)
  
  -Original Message-
  From: Kapil Thangavelu [mailto:[EMAIL PROTECTED]
  Sent: April 14, 2004 6:49 AM
  To: [EMAIL PROTECTED]
  Cc: [EMAIL PROTECTED]
  Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely
  r evis ion based storage for Zope ?)
  
  On Tue, 2004-04-13 at 20:53, [EMAIL PROTECTED] wrote:
   Hello,
   
   Hmmm, well it's as stable as Ape and Subversion are respectively :)
   
   I wouldn't call it stable no, it's something I did over the long week-end
  we
   just had, and that's about it :)
   
   Ape is at 0.8 and therefore becoming quite mature, I'd have to let others
   speak as to it stability however ...
   
   Subversion is also probably quite stable (It just reached 1.0), though I
   don't know how heavily tested it's been in a long running process (Might
  it
   have some memeory leaks ?) ...
  
  the svn apache server model is a long running process and is fairly
  stable on memory usage. the python bindings require doing some manual
  memory management, but the pool api makes it easy to deallocate
  arbitrary allocations safely. the cmfsvnbrowser code i ref'd early 
  has been in production by myself and others for almost a year and 
  runs with a stable memory footprint.
  
  -kapil
  


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

2004-04-18 Thread Kapil Thangavelu
On Wed, 2004-04-14 at 19:14, Shane Hathaway wrote:
 On Wed, 14 Apr 2004 [EMAIL PROTECTED] wrote:
 
  My initial, uneducated thoughts on the topic were simplistic, but then I'm a
  big K.I.S.S. fan: simply pickle the entire object back and forth as one
  entity.  This means for each object, there is one file on the fs.  The
  benefit is greater simplicity ... the downside is that you couldn't check
  those files out of subversion and interact with them.  I also have to
  imagine the former is faster ?
 
 If you store pickles, you can't merge, you can't store properties, in fact
 you can't even store folders as directories or keep track of references
 between objects.  At that point, you'd do much better to just use
 FileStorage--KISS, after all.  Ape's real utility is in breaking objects
 apart for storage.  If you don't need that, you don't need Ape.  But I
 like to think it makes the job of breaking objects apart for storage
 relatively simple.
 
  But if usnig the latter, then I'd think that in SVN there would be only 1
  file, written by a specific mapper for a specific content type, say image.
  the data written to the file is such that if checked out, the file works,
  so I can open it in photoshop or something.
  
  I however, would simply put everything else in properties, if that makes
  sense at all. Zope properties, security information, and so on.  1 porperty,
  1 piece of data. No need for reading/writing multi-line text.
 
 That's fine, although you'll need to distinguish Zope properties from 
 other kinds of properties.  For example, if some object has a class_name 
 Zope property, you'd be in trouble if the system mixed that up with the 
 class_name key of the object classification.

i don't think needs to much worrying about, just prefix zope properties
with 'zope:' much the same way svn does with its properties
'svn:externals'

 
  The only thing I'm not so sure about is this remainder ... Though if it
  really is a base64 encoded string, there's no reason not to put that in a
  property as well.
 
 That's correct, it's always base64 encoded (with some comments.)
 
  The benefits I see:
  
  - The filesystem reflects the object structure, no extra files lying around.
 
 Definitely.
 
  - a more consistent way to setup mappers/gateways: there's data, and
  there's everything else. Have a common/defined/smart way of handling
  everything else.
 
 I would recommend you defer this for a while.  Lots objects don't
 easily fit this model.  For example, what is the data of a CMF tool?  
 We can make plenty of progress on Subversion without thinking about 
 changing the way mappers are defined.
 
  - with the use of the properties related svn funtions, we better leverage
  SVN's features.
 
 Yup.
 

another thing to keep in mind here, svn is basically a versioned fs, and
in addition to node/content history tracking and it has
facilities/functions for apply deltas to content, and recieving delta
diffs back etc, but these apply to node/content bodies and not to
properties. ie. there are no facilties for diffing properties, and this
would need to be implemented in python.

-kapil


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

2004-04-18 Thread Kapil Thangavelu
On Wed, 2004-04-14 at 10:44, [EMAIL PROTECTED] wrote:
 The property schema thing is a good point, though I'm not sure we could ever
 do anything about it, not with the purpose to help naive gui clients work
 better with the repository.

agreed, its not something to worry about, and such naive clients are imo
broken.

 
 By nature the object structure (Class instance) is not fixed, so the
 amount/name/data of properties could vary arbitrarily.  This is after all
 the major benefit of an OODBMS.
 
 Fact is if one wanted a client to interact with a svn repository that stores
 zope objects, it would need to be fairly specifically designed for it ...
 How would a client (Say dreamweavnr with a subversion plug-in) know that
 when editing an image, the x and y size properties need to be updated ? What
 if someone monkey patches the image type to add some other
 property/attribute ?
 

well i think its also useful to think of svn as a sychronization point,
like an rdbms. for other processes in other languages to interact with
the content, like doing rich transforms/classification based on the
content and storing as properties. using proper names for properties i
think avoids the issue of dealing with client overlap, i would treat
properties as though they were in xml namespaces, ie serialize
dublincore author to dc:author, zope localroles - zsecurity:localroles,
etc. 

also its possible for zope to have total awareness of content changes
done by external clients ( i depend on this functionality actually to
reindex, get notification of deleted, apply wf to added content, etc.)
but all of this happens at an application level not the zodb layer.

 All we could hope to do is find a consistent and predictable way to handle
 properties, so that clients would know at the very least how to read/write
 them, but not necessarily know which one does what.  I suppose there's
 possible ways around that actually, by providing some way to describe
 properties and what they do and so on ... but that's beyond the scope of
 what I'm trying to do I think ...
 

it is beyond scope, at min it requires a schema set for commonly defined
properties which beyond the zope core properties are application
specific. i wouldn't worry about to well into the future.

-kapil

 J.F.
 
 -Original Message-
 From: Kapil Thangavelu [mailto:[EMAIL PROTECTED]
 Sent: April 14, 2004 6:51 AM
 To: Shane Hathaway
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely
 r evis ion based storage for Zope ?)
 
 
 On Tue, 2004-04-13 at 22:46, Shane Hathaway wrote:
  On Tue, 13 Apr 2004 [EMAIL PROTECTED] wrote:
  
   Thanks for the extra tips, I'll check out those interfaces! I'm also
 getting
   up to speed on the whole mapper concept, where the work regarding
 properties
   handling seems to be ?
  
  Ape supports both annotations and Zope properties.  Annotations are blocks
  of multi-line text, while Zope properties are less constrained.  On the
  filesystem, Ape stores many Zope properties together in a single
  annotation called properties.  Other annotations include object
  classification, the remainder pickle (encoded in base 64), and security
  information.
  
  What are the expectations and limits of Subversion properties?  If they
  are blocks of multi-line text, you can store the annotations as Subversion
  properties.  If not, we'll still need a .properties file.  (Note that 
  the name .properties is thus confusing.  Oops.)
  
 
 svn supports aribtrary property values. ie you can store binary
 (remainder pickles, object classification, etc.) of arbitrary size on
 them. there is some question of how well some naive gui client will do
 when trying to list such properties, as there is currently no notion of
 metaproperties/property schema beyond the property namespace for
 introspection of a property.
 
 -kapil



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

2004-04-18 Thread Kapil Thangavelu
On Thu, 2004-04-15 at 00:16, [EMAIL PROTECTED] wrote:
 Oh, a very good idea indeed! We'll have to look at that eventually.
 
 The mechanism you describe is preferable, but it should be noted that
 subversion properties are easily accessible using the clients.
 
 So long as said properties are human readable/writable, that's also an
 option.
 
 The main issue for me (And many others I suppose), is the fact that every
 single object type I use is either completely custom, or a monkey patched
 version of a built-in type (Notably OFS.Image for instance).
 
 So there would have to be a reliable serializer for other objects, which I
 beleive you already have, so that's OK :)


i dunno if you use or have tried archetypes, but it has experimental
support for generating the needed ape structures from its schema.. see 
archgenxml and archetypes/apesupport.. its pretty cool actually you cane
go from a uml model straight to a content model with support.

http://cvs.sourceforge.net/viewcvs.py/archetypes/Archetypes/ApeSupport.py?rev=1.6view=auto

cheers,

-kapil


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

2004-04-17 Thread Kapil Thangavelu
On Wed, 2004-04-14 at 19:28, Shane Hathaway wrote:

 In Subversion, is it possible to read/write a versioned object by unique
 identifier rather than by path?  If so, it's a great blessing and we don't
 need a transaction script.

not really, yes every svn node has an a node id, but there is no way to
retrieve a particular node from the svn fs via node id. it is possible
to compare to compare and see if their related, (part of the node id is
a copy id which gets incremented when a node is copied).

in short not really.

-kapil


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

2004-04-14 Thread Kapil Thangavelu
On Tue, 2004-04-13 at 20:53, [EMAIL PROTECTED] wrote:
 Hello,
 
 Hmmm, well it's as stable as Ape and Subversion are respectively :)
 
 I wouldn't call it stable no, it's something I did over the long week-end we
 just had, and that's about it :)
 
 Ape is at 0.8 and therefore becoming quite mature, I'd have to let others
 speak as to it stability however ...
 
 Subversion is also probably quite stable (It just reached 1.0), though I
 don't know how heavily tested it's been in a long running process (Might it
 have some memeory leaks ?) ...

the svn apache server model is a long running process and is fairly
stable on memory usage. the python bindings require doing some manual
memory management, but the pool api makes it easy to deallocate
arbitrary allocations safely. the cmfsvnbrowser code i ref'd early has
been in production by myself and others for almost a year and runs with
a stable memory footprint.

-kapil


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

2004-04-14 Thread Kapil Thangavelu
On Tue, 2004-04-13 at 22:46, Shane Hathaway wrote:
 On Tue, 13 Apr 2004 [EMAIL PROTECTED] wrote:
 
  Thanks for the extra tips, I'll check out those interfaces! I'm also getting
  up to speed on the whole mapper concept, where the work regarding properties
  handling seems to be ?
 
 Ape supports both annotations and Zope properties.  Annotations are blocks
 of multi-line text, while Zope properties are less constrained.  On the
 filesystem, Ape stores many Zope properties together in a single
 annotation called properties.  Other annotations include object
 classification, the remainder pickle (encoded in base 64), and security
 information.
 
 What are the expectations and limits of Subversion properties?  If they
 are blocks of multi-line text, you can store the annotations as Subversion
 properties.  If not, we'll still need a .properties file.  (Note that 
 the name .properties is thus confusing.  Oops.)
 

svn supports aribtrary property values. ie you can store binary
(remainder pickles, object classification, etc.) of arbitrary size on
them. there is some question of how well some naive gui client will do
when trying to list such properties, as there is currently no notion of
metaproperties/property schema beyond the property namespace for
introspection of a property.

-kapil


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?)

2004-04-14 Thread Kapil Thangavelu
On Tue, 2004-04-13 at 12:01, Shane Hathaway wrote:
 On Tue, 13 Apr 2004, Kapil Thangavelu wrote:
 
  since
  objects modified in a version are in essence locked from participating
  in other transactions, actions like modifying content in a version in a
  cmf site amounts to locking the catalog from changes outside of the
  version, which amounts to shutting down write activities to a cmf site.
 
 This is only true of FileStorage.  Some other storage could implement ZODB
 versions with merging capability rather than locking.
 

good point, just because hasn't been doesn't mean it can't ;-)

although i wonder if there is some hand waving in progress here that i
can't see. i guess my semantic notion of versions has been that of long
lived transactions, and is there a better means of thinking of them? how
do they play across with multiple mounted zodbs? what would something
like merge mean in the context of a catalog?

  i'm also curious how you dealt with svn transactions as part of the ape
  integration work to date.
 
 The same way it tries to impose transactions on the filesystem: in the 
 vote phase, Ape looks for possible problems and aborts early if it detects 
 anything that will cause the transaction to fail.  Obviously, this 
 provides no guarantee, but covers many cases.
 

i was more curious how jean-francois was doing the svn ops in fileops,
as svn is fundamentally a transactional store (as opposed to the fs), ie
is there some record boundary notion of ape signalling the end of
serialization for an object set, or was each operation being conducted
in a separate svn transaction.

-kapil


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?)

2004-04-14 Thread Kapil Thangavelu
granted the svn integration has lots of coolness factors including
richer client integration, but things like zope version control
(zope.org cvs) are already production quality and not so hard to
integrate in for basic version control.

-kapil

On Tue, 2004-04-13 at 14:13, Arthur Chan Chi Chuen wrote:
 Hi all,
 
 I've read your discussion about version control, it seems a cool thing you 
 guys making good progress. Btw, can I ask is the Ape using Subversion in Zope 
 stable? how able CMF stuff? I wanna make/find a document management system 
 which can provide some kinda version control in Plone.
 
 Thanks
 Arthur
 On Tue, 13 Apr 2004 04:06:26 -0400, Kapil Thangavelu wrote
  On Mon, 2004-04-12 at 18:03, [EMAIL PROTECTED] wrote:
   G'Day,
   
   Well, step one is done ... I now have Zope + Ape using Subversion as it's
   filesystem !!
  
  
  cool!
  
   This is step one because, as Shawn suggested (Thanks for the pointer, 
 that's
   what I needed!), this simply means that Zope uses SVN purely as a
   filesystem.
  
  
   Because of subversion's nature, I want to look at 2 things beyond this 
 that
   traditional filesystems don't support:
   
   - Use zope's username for SVN logging.
  
  using AccessControl.getSecurityManager().getUser().getId() and 
  setting it up as a revision prop ( or directly when creating the 
  repo transaction) should do it.
  
   - History/Undo support: View past revisions of an object, and revert to 
 such
   a past revision.
  
  perhaps the code for this would be helpful, (remove image for code 
  link) 
 http://zope.org/Members/k_vertigo/Products/CMFSubversionBrowser/FileRevisions.
 png
  
   - Zope Version support: SVN is fully transactional and atomic, this should
   allow for support of Zope versions (I think ?)
  
  
  zope version support isn't really all that worthwhile, esp in a cmf
  context. in general zope's version support (or zodb more 
  particularly) is a database level feature masquerading as an 
  application one. since objects modified in a version are in essence 
  locked from participating in other transactions, actions like 
  modifying content in a version in a cmf site amounts to locking the 
  catalog from changes outside of the version, which amounts to 
  shutting down write activities to a cmf site. otoh, integration with 
  zope's transaction manager would be a good thing, although its 
  problematic to integrate between svn and zope txn models, more on 
  that in a moment.
  
   In the longer term, there's great opportunity for:
   
   - Built-in conflict management and resolution: No more need for a
   SafetyBelt type approach.  Right now I haven't looked at this at all.  I
   plan to implement smart merging where possible (It might work already
   actually, I just need to test it).  True conflicts (Where a merge can't be
   accomplished withouth user interaction) would raise some sort of conflict
   error.
  
  
  i don't know that conflict management is really useful in this context.
  svn like zope relies on optimistic concurrency control, and currently
  doesn't support dav locking (which zope does). ie, it will just 
  throw an error if the content has been changed since the transaction 
  began. the 'normal' concurrency control of svn is better but 
  dependent on using the working copy (wc) layer, which is additional 
  programming and storage overhead. so at the layer of the svn client 
  this is already done and working and good, but integrating this 
  functionality into zope is a bit harder without wc overhard.
  
  this also makes the transaction integration becomes harder because both
  zope and svn are using what amounts to optimistic concurrency control
  which makes it impossible afaics, to get real txn integration, ie in
  zope's two phase commit strategy, the last chance for a participant 
  to safely abort is tpc_vote, but there is no real way of knowing if 
  the svn txn will suceed or not until its tried. if it is tried at 
  this stage and succeeds then there is the possibility of a latter 
  txn participant failing the tpc_vote and the txn being aborted, and 
  if waits till tpc_finish (last part of two phase commit) and the svn 
  txn fails it can hose the composite txn integrity.
  
  once svn supports dav locks, doing txn integration via resource locking
  as part of tpc_vote (or earlier) would be possible, till then.. i 
  dunno, i can't see a way around this for real txn integration.
  
  i'm also curious how you dealt with svn transactions as part of the ape
  integration work to date.
  
   - Editing Zope content objects through interaction with the svn 
 repository.
   I can checkout the repository, edit some objects, and chek them back in,
   never interacting with Zope directly ... I've already tried this !  Works
   great for text based content types such as PageTemplates or DTML Documents
   and so on ... I even did it with a JPG, though because the properties hold
   width and height, you get some weird

Re: [Zope-dev] Re: [Zope3-dev] Zope and zope

2004-04-14 Thread Kapil Thangavelu
On Wed, 2004-04-14 at 09:00, Jim Fulton wrote:

 The first question is:
 
 Is it a problem to have two packages with names differing only in case?
 
snip
 
 Perhaps we can get more input on whether there's a problem.

 A response with a positive sign (e.g. +1, +0, +2, ...) indicates
 agreement that this is a probelm. :)

+1 

its probably a problem imo for mac users who are on a case insensitive
fs. 

none of the alternative seem all that appealing though.. the comment
about most z3 imports being prefixed with zope, suggests that any
backwards porting with a goal of forward compatibility will require
changing the existing z2 Zope package to something else, although
sticking version numbers on package names doesn't hold much appeal for
me. perhaps renaming z2 Zope-Core

-kapil


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: [patch] More secure cookie crumbler?

2004-04-13 Thread Kapil Thangavelu
fwiw, Simon Eisenmann checked in a SessionStorage product into the
collective which does much the same. released under the zpl

http://cvs.sourceforge.net/viewcvs.py/collective/SessionCrumbler/

-kapil



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?)

2004-04-13 Thread Kapil Thangavelu
On Mon, 2004-04-12 at 18:03, [EMAIL PROTECTED] wrote:
 G'Day,
 
 Well, step one is done ... I now have Zope + Ape using Subversion as it's
 filesystem !!
 

cool! 

 This is step one because, as Shawn suggested (Thanks for the pointer, that's
 what I needed!), this simply means that Zope uses SVN purely as a
 filesystem.
 

 
 Because of subversion's nature, I want to look at 2 things beyond this that
 traditional filesystems don't support:
 
 - Use zope's username for SVN logging.

using AccessControl.getSecurityManager().getUser().getId() and setting
it up as a revision prop ( or directly when creating the repo
transaction) should do it.

 - History/Undo support: View past revisions of an object, and revert to such
 a past revision.

perhaps the code for this would be helpful, (remove image for code link)
http://zope.org/Members/k_vertigo/Products/CMFSubversionBrowser/FileRevisions.png

 - Zope Version support: SVN is fully transactional and atomic, this should
 allow for support of Zope versions (I think ?)
 

zope version support isn't really all that worthwhile, esp in a cmf
context. in general zope's version support (or zodb more particularly)
is a database level feature masquerading as an application one. since
objects modified in a version are in essence locked from participating
in other transactions, actions like modifying content in a version in a
cmf site amounts to locking the catalog from changes outside of the
version, which amounts to shutting down write activities to a cmf site.
otoh, integration with zope's transaction manager would be a good thing,
although its problematic to integrate between svn and zope txn models,
more on that in a moment.

 In the longer term, there's great opportunity for:
 
 - Built-in conflict management and resolution: No more need for a
 SafetyBelt type approach.  Right now I haven't looked at this at all.  I
 plan to implement smart merging where possible (It might work already
 actually, I just need to test it).  True conflicts (Where a merge can't be
 accomplished withouth user interaction) would raise some sort of conflict
 error.
 

i don't know that conflict management is really useful in this context.
svn like zope relies on optimistic concurrency control, and currently
doesn't support dav locking (which zope does). ie, it will just throw an
error if the content has been changed since the transaction began. the
'normal' concurrency control of svn is better but dependent on using the
working copy (wc) layer, which is additional programming and storage
overhead. so at the layer of the svn client this is already done and
working and good, but integrating this functionality into zope is a bit
harder without wc overhard.

this also makes the transaction integration becomes harder because both
zope and svn are using what amounts to optimistic concurrency control
which makes it impossible afaics, to get real txn integration, ie in
zope's two phase commit strategy, the last chance for a participant to
safely abort is tpc_vote, but there is no real way of knowing if the svn
txn will suceed or not until its tried. if it is tried at this stage and
succeeds then there is the possibility of a latter txn participant
failing the tpc_vote and the txn being aborted, and if waits till
tpc_finish (last part of two phase commit) and the svn txn fails it can
hose the composite txn integrity. 

once svn supports dav locks, doing txn integration via resource locking
as part of tpc_vote (or earlier) would be possible, till then.. i dunno,
i can't see a way around this for real txn integration.

i'm also curious how you dealt with svn transactions as part of the ape
integration work to date.

 - Editing Zope content objects through interaction with the svn repository.
 I can checkout the repository, edit some objects, and chek them back in,
 never interacting with Zope directly ... I've already tried this !  Works
 great for text based content types such as PageTemplates or DTML Documents
 and so on ... I even did it with a JPG, though because the properties hold
 width and height, you get some weird looking pictures :) The concept is
 valid though.  There may someday be a way to leverage this functionality
 better with a purpose built client of some sort.


to me this is one of the fundamental benefits of using svn, giving users
the ability to use interfaces like tortoisesvn (win shell extensions) or
mac finder extensions to interact directly with content.

 
 - Leveraging SVN's property management.  Content in SVN has properties, much
 like Zope does.  I haven't looked at it yet, but I've noticed .properties
 file appearing ... I'm guessing those are the Zope properties, which would
 be better handled by subversion's property mechanism.  And properties are
 versioned too !

definitely!



 
 In the realm of the wishful thinking, there's even more:
 
 Right now, HEAD (Latest/youngest revision) is always used and worked with.
 The really powerful feature I want to eventually 

[Zope-dev] Re: Proposal: Move to subversion for source code control of the Zope and ZODB projects

2004-04-12 Thread Kapil Thangavelu
fwiw, i've been able to get good results at migrating the plone
repository and branches using the refinecvs migration script
http://lev.serebryakov.spb.ru/refinecvs/

the cvs2svn script included with subversion had several issues with
branches, although it was a few months ago (prior to svn 1.0) that i
last attempted to use it.

with a little luck plone will be on svn before the end of the month.

i've also setup some one way cvs-svn sync scripts for mirroring
zope.org cvs into an svn repository to allow for automated pull of
dependencies via svn:externals.

-kapil

On Mon, 2004-04-12 at 08:44, Sidnei da Silva wrote:
 On Mon, Apr 12, 2004 at 08:11:44AM -0400, Tres Seaver wrote:
 | Lennart Regebro wrote:
 | From: Jim Fulton [EMAIL PROTECTED]
 | 
 | Initially, I propose to move just the repository heads. Maintenamce
 | branches (e.g. Zope 2.6 and Zope 2.7) will remain in CVS.
 | 
 | What is the rationale behind not moving it all?
 | 
 | Risk mitigation;  we have significant support requirements for deployed 
 | systems built around CVS for both 2.6- and 2.7-based sites, whereas the 
 | head and Zope3 have no such inertia.  We don't know enough about the 
 | migration process to have any confidence that existing history / 
 | branches, etc., won't be somehow messed up, which makes it prudent to 
 | plan the migration around the already-unstable bits.
 
 Just FYI, Kapil has been doing a good job at improving the script that
 migrates from CVS to SVN, and we are ready to flip the switch to move
 Plone, Collective and possibly Archetypes to SVN.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZODB with twisted web.

2004-04-04 Thread Kapil Thangavelu
On Fri, 2004-04-02 at 17:37, Dieter Maurer wrote:
 Syver Enstad wrote at 2004-4-2 11:38 +0200:
 I am checking out how to use ZODB with twisted web. I thought that I
 would have the DB instance globally accesible and call the open method
 to get a connection on each request. I thought that if I use
 connection.getTransaction().commit() before sending the response I
 will commit on the connection for that request. Is this necesarily
 true when using twisted web because it is single threaded and it seems
 that ZODB finds the correct transaction by checking the thread.
 
 This is true only, when you are working with local transaction mode
 (i.e. you are calling connection.setLocalTransaction()).
 
 Currently, this mode restricts you to a single transaction client.
 Neither relational databases nor other transactional clients
 understand this mode. Moreover, you cannot use DBTab to
 mount several ZODB storages.
 

i wouldnt say it restricts you to a single txn client, local transaction
mode with twisted allows for the primary goal of using single threaded
twisted with zodb txn semantics bound to protocol instances/clients, and
the txn framework is still perfectly capable, just that the resource
integration of other txn aware resources needs to play well with zodb
conn based txns, which basically rules out most of the existing zope
products as they use a global accessor to the transaction as opposed to
call getTransaction on a conn which would still allow zodb to play a txn
authority/manager role. but at the level of using twisted and zodb
directly those products wouldn't likely be all that useful.

-cheers,

-kapil



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] strange path

2004-03-20 Thread Kapil Thangavelu
most likely Concepto object id is not being set properly.

this question should be addressed to [EMAIL PROTECTED] 

this list is for the development *of* zope itself not development with
zope.

-kapil

On Sat, 2004-03-20 at 10:51, Garito wrote:
 Hi
  
 on a ZPT I put a here/absolute_url and these is the response:
  
 http://localhost:8080/Plantillas/Pruebas/Objetos///Minima
  
 the correct path would be:
  
 http://localhost:8080/Plantillas/Pruebas/Objetos/Concepto/Vistas/Minima
  
 What's happening here?
  
 TIA
 
 __
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Question about _v_ attributes and database connections

2004-03-11 Thread Kapil Thangavelu
fwiw, i think this is a viable solution (although you should not only
scope connections to thread local but to da paths in the module level
global) as there are problems with zope and das going away because of
their volatiles.. it can lead to strange behavior, like say your in the
midst of a long txn, the da conn is involved gets registered w/ the txn.
during the course of the txn the da persistent object is ghosted, latter
it comes back but it will do so with a different connection if used
again, this is bad from an rdb txn isolation pov, because assuming any
isolation it can't see the changes done with the other as yet
uncommitted connection (still alive cause its ref indirectly from the
zope txn itself).
 
unfortunately this is arch. problem with zope and current rdb/da
integration and the only real solution that i see is via module level
global storage for conns.

as for shutdown of these conns, easiest might be to register an atexit
function, or a cleaner sweeper thread with last usage times and in txn
status on the otherwise thread local conn storage.

cheers,

-kapil
 
On Thu, 2004-03-11 at 06:56, Marco Bizzarri wrote:
 On Thu, Mar 11, 2004 at 11:49:34AM +, Chris Withers wrote:
  Marco Bizzarri wrote:
  
   I'm trying something inspired to that at the moment... I succeeded in
   installing an hack, very inspired from your code (but at a much simpler
   level) and some code in the SecurityManager,
  
  ?!
 
 Look in AccessControl/SecurityManagement.py, the getSecurityManager()...
 it does in that way.
 
   where I mantain a dictionary
   of connections, indexed by the result of thread.get_ident(). 
  
  :-(
 
 I know, it is an hack :(
 
   Once a
   thread needs a new connection, either it is present in the dictionary
   or not. If it is present, give it to the thread and assign that to the
   _v_database_connection attribute. Otherwise, create a new one, put in
   the dictionary, and go on as before.
  
  When do these connections get closed?
 
 Never, for the moment.
 


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


RE: [Zope-dev] Serving big files thru zope?

2004-03-04 Thread Kapil Thangavelu
you could play with
http://puggy.symonds.net/~srp/stuff/mod_auth_remote/

and have apache auth off zope.

cheers,

-kapil

On Mon, 2004-03-01 at 11:06, Sandor Palfy wrote:
  I am also wondering about the security aspects of bypassing Zope to 
  serve files - acess to some of the files we need to serve is 
  restricted 
  to particular users with particular permissions, and I cannot clearly 
  see how this would be possible to accomplish without Zope's security 
  machinery.
 
 Same situation here. Is there any way to provide authentication
 information for Apache from Zope (which works at least with cookie based
 auth)? 
 
 Regards,
 Sandor
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )
 


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Custom class: cut,copy,rename?

2004-03-04 Thread Kapil Thangavelu
On Mon, 2004-03-01 at 13:59, Ian Beatty wrote:
 Greetings.
 
 I've created a package in Python with some basic classes. They work in the
 ZMI, except for the fact that the ZMI paste and rename functionality fails
 with the message The object xxx does not support this operation.
 
 I've dug into the source code for standard types ('OFS.Folder',
 'OFS.SimpleItem', etc.) and discovered some tantalizing bits (such as
 'manage_renameObject' in 'OFS.CopySupport'), but I can't figure out how to
 put it together to make my classes renameable and pasteable. I'm rather
 surprised that behavior doesn't come automatically when inheriting from the
 standard base classes.
 
 One of my folderish classes subclasses the following bases:
 
 OFS.ObjectManager.ObjectManager
 Products.ZCatalog.CatalogPathAwareness.CatalogAware
 OFS.PropertyManager.PropertyManager
 OFS.SimpleItem.SimpleItem
 
 Am I not inheriting from the proper set of base classes? Is there an easier
 way? According to the ZDG (2.4 edition, vs. my Zope 2.7),
 OFS.SimpleItem.Item (subclassed by OFS.SimpleItem.SimpleItem) is supposed to
 provide cut-and-paste functionality. So, how might I be breaking it?
 

as i recall the default copy paste behavior is a bit arcane in that the
verify tries to assert the object is indeed a registered meta_type (ie
reg. in initialize) so that it can verify permissions, see cmfcore
folder code for an example of making a custom container which works
around this (basically just override _verifyObjectPaste), or just
register the objects.

cheers,

-kapil


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Non Bloating Page Counter

2002-11-08 Thread kapil thangavelu
On Friday 08 November 2002 01:55 pm, Dieter Maurer wrote:
 Brian R Brinegar writes:
   We've had requests from several of our users for the ability to have a
   drop in page counter within zope. However creating a page counter python
   script which increments some value in zope will bloat the ZODB.
  
   Solutions exist where values are stored on the file system or in a
   database. Unfortunately our users don't have file system access and it
   is unacceptable to expect them to request a database account and setup
   database connections and methods just to create a page counter.
  
   I would like to create a Page Counter product that doesn't bloat. If a
   product is created that doesn't subclass History or UndoSupport does it
   still bloat?

 It does.

 The bloat is a consequence of how FileStorage works (I appends
 changes at the end of the file and does never override something).

 You need a different storage (a non-undoable one) to prevent
 this behaviour, e.g. BerkeleyStorage or OracleStorage.

is there a useable undoable storage?

 When your load is light and your counter consists justs of
 an integer, then your bloat is only several dozens of byte
 and you may be able to live with it


if you can live with that, then you should try to use a subclass of 
lib/python/BTrees/Length.py

more efficient pickling state and app conflict resolution.

stepping up beyond that while remaining in the zodb means using something like 
the strategy casey suggested of updating in memory variables and committing 
them periodically (and you definitely want conflict resolution for something 
like that on your persistent ob).

-k



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] User Module

2002-11-07 Thread kapil thangavelu
first, these questions are better directed at [EMAIL PROTECTED], this list is for 
discussion for development of the zope server, not development on zope.

second, another good resource, the #zope irc channel on openprojects is a 
wealth of friendly helpful people.

-kapil

On Thursday 07 November 2002 08:36 pm, Karthikeyan wrote:
 Thanks Lennart and Wei for the comments.

 But i need to design something to show and convince somebody. Pls help me
 with some modules to start.

 Lennart, The acl users you are taking about is coming with the management
 screen. I need to create a page to register a person and make him login
 thru my page. Pls let me know. Thanks


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] 2.6 MIA

2002-07-23 Thread kapil thangavelu

whats the release plan for 2.6? 

is it time for another alpha/beta release?

curious,

kapil


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] DirectoryViews for Zope2.6?

2002-06-05 Thread kapil thangavelu

On Tuesday 04 June 2002 10:24 pm, Robert Rottermann wrote:
 I agree with you.
 And they depend on CMF only very ligthly. So taking them out of CMF should
 be easy.

indeed it was.

http://www.zope.org/Members/k_vertigo/Products/FileSystemSite

i don't have the unit tests ported over, but they are included with the 
distro.

-kapil


 Robert
 - Original Message -
 From: kapil thangavelu [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Thursday, May 30, 2002 3:09 AM
 Subject: [Zope-dev] DirectoryViews for Zope2.6?

  hi folks,
 
  i was wondering if there is interest (or possiblity) of including

 directory

  views in zope2.6. i've been using them for team development with zope,
  and i've come to think their a fantastic dev. method in combination with
  cvs.
 
  any takers?
 
  cheers
 
  kapil


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] DirectoryViews for Zope2.6?

2002-06-04 Thread kapil thangavelu

hi folks,

i was wondering if there is interest (or possiblity) of including directory 
views in zope2.6. i've been using them for team development with zope, and 
i've come to think their a fantastic dev. method in combination with cvs. 

any takers?

cheers  

kapil



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] putting the 'two' back in tpc

2002-06-04 Thread kapil thangavelu

+1 for adding _vote() to TM.py

all XAs/DMs should have voting privleges, even if they don't exercise such.

the default behavior should be due to nothing, for as with people in a 
democracy most  tm subclasses won't vote.

-kapil

On Tuesday 04 June 2002 12:54 pm, Leonardo Rochael Almeida wrote:
 In a chat with Kapil at #zope we came to the conclusion that most Zope
 database adaptors don't really implement two phase commit, because they
 make no effort, during the 'vote' phase (the first phase of the tpc) to
 make sure that the commit will go thru without errors.

 For example, if you have the following schema in postgresql:

 CREATE TABLE passwd (
 username character varying(64) UNIQUE,
 password character varying(64) NOT NULL,
 roles character varying(255),
 Constraint passwd_pkey Primary Key (username)
 );

 CREATE TABLE userproperties (
 username character varying(64) NOT NULL references passwd
 (username) DEFERABLE INITIALLY DEFERRED,
 propname character varying(128) NOT NULL,
 value text NOT NULL,
 );

 This schema allows an entry in the 'userproperties' table to exist
 without an equivalent user in the 'passwd' table before the end of the
 transaction.

 If, on commit, there still isn't a user with the same 'username' on the
 'passwd' column, postgres will raise an error and won't let the commit
 go thru.

 Now all the current DA implementations that I know of call the database
 commit only in the second (or finish) phase of the tpc, which will
 result in a locked down Zope, as Zope is not very much fond of people
 bailing on him on the second phase.

 Now the correct solution for this, as far as postgres is concerned, is
 to execute the query, 'SET CONSTRAINTS ALL IMMEDIATE' in the 'vote'
 phase, since no other query will be executed between this query and the
 commit. Postgresql will raise an error while trying to execute this
 query if any coinstraint is yet to be satisfied, so Zope will be able to
 cancel the transaction to all those registered in the transaction
 machinery. And if the postgresql documentation is correct, 'SET
 CONSTRAINTS...' is an SQL92 and SQL99 standard, so other db's might be
 able to benefit from this.

 The problem is that lib/python/Shared/DC/ZRDB/TM.py doesn't provide a
 _vote() slot which should be called by tpc_vote(). TM documentation
 should mention that this slot should be overriden, just like _finish()
 and _abort(). It should also mention why this slot should be overriden
 (consistency this, consistency that, yadda yadda..).

 The nazi bastard in me wants the default implementation of this slot to
 raise an error to remind people to override it. If your DA doesn't need,
 or can't, implement a _vote() for some reason, you should explicitly
 override it to do nothing. However I know that breaking other people's
 DA is not nice :-)

 The not so nazi bastard in me says that the default _vote()
 implementation should zLOG a warning about '_vote()' not being
 implemented, but I know that even this might be too much to ask, since
 logfiles everywhere would go crazy.

 Anyway, this may be a little late, but I believe that implementing a
 do-nothing _vote() that is called by TM.tpc_vote() is a small and
 unintrusive change but a change that is important enough to deserve to
 be included in 2.6, so that DA authors take notice and implement it
 where possible.

 I'd volunteer to make this change myself if my commiter's agreement had
 been commited (I'm looking at you Paul Everitt). I know that I'll bug
 the Psycopg guys once this change is thru.

 Leo


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] python question

2002-04-27 Thread kapil thangavelu

On Saturday 27 April 2002 08:44 am, Andy McKay wrote:
 Look at pydoc http://www.google.ca/search?q=pydochl=enmeta=

last i tried it, pydoc has issues with some zope stuff, its also distracting 
and educational to realize how much support stuff zope mixins... 

happydoc is a nice tool that differs mainly in that its analyzing structuring 
rather than importing and inspecting ala pydoc.

-k

 - Original Message -
 From: Dirk Datzert [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Friday, April 26, 2002 10:39 AM
 Subject: [Zope-dev] python question

  Hi,
 
  does anybody know a good programm or the command to create documentation
  of python classes (api-documentation like javadoc) out of the python
  code ?
 
  Thanks,
  Dirk
 
 
 
  ___
  Zope-Dev maillist  -  [EMAIL PROTECTED]
  http://lists.zope.org/mailman/listinfo/zope-dev
  **  No cross posts or HTML encoding!  **
  (Related lists -
   http://lists.zope.org/mailman/listinfo/zope-announce
   http://lists.zope.org/mailman/listinfo/zope )

 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] How about a Bug Day this Friday?

2002-04-08 Thread kapil thangavelu

On Monday 08 April 2002 12:40 pm, Brian Lloyd wrote:
 Hi all -

 A while back I posted a summary of the semi-regular
 bug days we'd like to start having:

 http://dev.zope.org/CVS/BugDays

 We are planning to have the inaugural bug day this
 Friday (April 12th) from around 9 a.m. US /Eastern
 until we've all had enough :^)

 If things go well, I'd like to see this become a
 regular thing (say the second Fri. each month).

 Whaddya think?

sounds great.

cheers

kapil  (irc hazmat)


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] Re: [Zope] isecure XML-RPC handling.

2002-04-02 Thread kapil thangavelu


he's testing against zope.org  

and the traceback is enclosed html comments, which probably does mean it is 
debug mode.

as for the concerns... i leave that to others.

-k


On Tuesday 02 April 2002 12:18 pm, Chris McDonough wrote:
 You are running Zope in debug mode (with the -D switch in the start
 file). This is the default.  Please try running Zope in non-debug mode
 (remove the -D switch) and try this again.

 - Original Message -
 From: Rossen Raykov [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Sent: Tuesday, April 02, 2002 2:33 PM
 Subject: [Zope] isecure XML-RPC handling.

  Zope is not handling correct XML-RPC request.
 
  Even the example from http://www.zope.org/Members/Amos/XML-RPC is not
  working.
 
  Even worst if a request like this one in the quoted example is send to
  the web server it will report information about the local server
  installation and the internal network.
 
  Included are a request and response to www.zope.org.
 
  As one may see the server is installed in
  /usr/local/base/Zope-2.3.2-modified/
  and it rely on 10.0.11.3:1380 for request processing.
 
  All this may be useful debug information but it is not acceptable for a
  production server!
 
  I'm not familiar with Zope and I cannot say is it only a configuration
  problem or it is a problem in the code.
 
  I do not have time to investigate that but a similar result may be

 achieved

  with the distribution offered for download.
 
  Please let me know if I have to send this bug information to some one

 else.

  I would like to be informed and when this issue is resolved so I can
  announce it on Bug-Traq.
 
  Regards,
  Rossen Raykov
 
  cut here
  $ telnet www.zope.org 80
  Trying 63.102.49.33...
  Connected to www.zope.org.
  Escape character is '^]'.
  POST /Foo/Bar/MyFolder HTTP/1.0
  Content-Type: text/xml
  Content-length: 95
 
  ?xml version=1.0?
  methodCall
   methodNameobjectIds/methodName
   params/
  /methodCall
 
 
  HTTP/1.0 500 Internal Server Error
  Server: Zope/Zope 2.3.2 (source release, python 1.5.2, linux2)


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Underscore trouble.

2002-03-12 Thread kapil thangavelu

rename your columns in the select statement,

this question belongs on [EMAIL PROTECTED]

-kapil

On Tuesday 12 March 2002 03:23 am, Romain Slootmaekers wrote:
 Yo,

 We have to connect to an existing database from zope.
 In this database, some of the fieldnames start with an underscore (fi
 _url). Zope sees these as protected and raises an exception when
 we try to access the tables with a select...

 Is there a way to disable this Zope 'feature' on ZMySQL methods ?

 TIA,

Sloot

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Help System Searches

2002-03-11 Thread kapil thangavelu

would it make sense to make the help system still allow searching but do 
storage in a mounted zodb ? 

cheers

kapil



On Saturday 09 March 2002 10:55 am, Chris McDonough wrote:
  There is no way to fix this? What other problems are there with the
  help system?

 Not that I can think of.  Other problems with the help system are
 presentation, mostly.

  Would it somehow be possible to make the helpsystem ignore versions?

 No, unfortunately.  It uses the Catalog, which is based on ZODB, and it
 puts a Catalog instance into the main FileStorage, which is undoing and
 versioning.  It then proceeds to do writes to the database when it
 appears that all you're doing is reading a pre-existing page.  If you're
 in a version at the time, a set of objects will be written into the
 Catalog and into other places in instance space that  have version.
 This is a bad pattern, and the only way to fix it is to prevent it from
 happening, which requires some helpsystem architectural changes that
 amount (IMHO) to a rewrite.

 - C

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] Transaction Bugs

2002-03-11 Thread kapil thangavelu

I wrote some unittests to investigate some odd transaction
behavior i noticed while doing unittests of integrating non 
sub transaction aware objects, and to insure proper txn behavior.
these tests test the transaction system independent of the rest 
of the zodb and test failure modes as well.

i've found a few bugs. 

1. TM.py ignores calls to tpc_abort. this i believe is the 
likely cause of most of the rdbms integration problems that
are referenced above as TM.py generally forms the integration
point between db adapters and zope's transaction framework. 
if an error occurs in the two-phase-commit protocol, the database
adapter will never recieve a finish/commit or abort message, and
will therefore (due to how TM works) never be able to register 
again for a zope transaction.

2. A Non Sub Transaction aware object (including any TM derived
object) that participates in a sub-transaction will recieve 
a tpc_finish message (which for TM derivatives calls _finish) 
as part of the subtransaction commit process. this means that
if the outer transaction is latter aborted, there will be a
loss data integrity.

3. As part of the commit process for a transaction involving
subtransactions, any objects registered since the last subtransaction
commit will be involved in an implicit subtransaction commit. 
if an error occurs during this implicit subtransaction, none
of the objects registered previously to the last explicit
subtransaction commit will recieve any messages. i'm not sure totally
sure this is a bug since any calls to explicitly begin a new
transaction should abort the objects that haven't recieved any
transaction messages. in a zope setting this is done automatically,
however standalone users should be aware of this.

i've posted a modified TM.py to my zope.org member page that
contains fixes/workarounds for problems 1 and 2. 

http://www.zope.org/Members/k_vertigo/ShortStories/Transaction/

in addition the unittests i've been using are posted there
as well. i'll commit these changes to TM.py latter today, but
have posted the above to zope.org for those who don't want
to immediately upgrade. actual fixes for problems 2 and 3 i'll 
leave to ZC.
 
if you're using a rdbms with zope, i would recommend 
installing the modified TM.py in replace of the exiting TM.py at 
lib/python/Shared/DC/ZRDB/TM.py. i would appreciate any 
feedback from rdbms users who were previously experiencing 
problems.

if this does not solve your problem, and you believe its
the fault of the transaction system, please email me. i don't 
use an rdbms with zope, but i'm happy to further investigate.

cheers

kapil thangavelu

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Zope 2.6 planning - call for contributors!

2002-03-06 Thread kapil thangavelu

On Wednesday 06 March 2002 04:58 am, Joachim Werner wrote:
 Hi!

 What I'd expect from Zope 2.6 depends a bit on when Zope 3 will be
 available.

 If we are talking about a couple of months, I'd prefer only having bug
 fixes in 2.5.x (and no 2.6 at all). If we are talking about more than half
 a year, or even a year from now, things look different.

 The problem is that all time that is invested into Zope 2.6 will be lost
 for Zope 3 development, but on the other hand I can't imagine how I would
 convince a customer to fund Zope 3 development if the results will not be
 useable soon.

 So what we actually need is a Zope 2.5.x to 3 migration path and plan that
 justifies investments in either Zope 2.6 or Zope 3. For that, we'll have to
 answer a few questions, like

 - Are there any components in the Zope 3 development cycle that can be
 backported to the 2 series? 

personally i would be interested in a backport of the component architecture, 
but i think that focusing development efforts on the zope3 core, is a more 
useful allocation of resources. zope3 will be ready faster the more people 
are willing to work on it. i know that i've been guilty of having not worked 
on it, since i have need to finish developing projects now on zope2 before i 
get to work on it.

that said, i really like some of the proposals on the table for 2.6, but i 
just don't think that backporting zope3 to zope2 is a good use of people's 
time.

 - Can we build stuff into 2.6 that makes people start thinking the Zope 3
 way?
 - ...

in this regard the component architecture would make the most sense... but 
again it would be fairly much a developer resource, and without the 
components, services, and utilities themselves it would just be lookup and 
structure to applications. most of whats in zope3 currently is architecture.

 I don't want Zope to end up like ArsDigita's ACS. They had a perfectly
 working 3 series that had all the features you'd expect, but was butt ugly
 in terms of the actual implementation. Then they started from scratch (like
 Zope is doing now) and built ACS 4, which was well-designed, but buggy as
 hell and had only core functionality. The plugins had not been ported yet.
 Then they started from scratch again and ported to Java (which Zope will
 not do I guess).


regarding the acs4

there were many plugins (dude, packages is the preferred nomenclature ;) 
ported to the acs4 architecture. in fact there are more of them then there 
were for the 3x platform (partly in due to improved modularity). that 
platform still lives on and thrives today in the form of the openacs. and 
includes some services and functionality in the core that i hope zope3 will 
bring to zope land (package management, workflow, calendaring/events, etc...)

the move to java and the fall of arsdigita came as direct result of tasting 
too much of that poisoned apple, known as venture capital.

 Currently there are 500 or so freely available Zope add-ons on zope.org,
 which will most probably not work on Zope 3, at least not with the 3X
 series. And there are even more non-free Zope products people have built on
 the 2 platform.

 I have the feeling that many of the add-ons will not be needed for Zope 3
 because Zope 3 will do better out-of-the-box. But for many others there
 must be a migration path.

i don't know how much discussion there has been on this, but its something 
worth discussing in more detail, namely the use of the ZopeLegacy system for 
zope2 products. when things are a little more settled down for zope3, an 
excellent piece of documentation would be a product porting guide.

 Let's take the database adapters. If Zope 3 does not support the major
 databases from the beginning, it might not get the momentum it needs.

completely apriori, i think these will be a fairly easy thing to port ;) .

 Slightly off topic, I think what Zope (2 AND 3) need really urgently is
 another layer on top that delivers what the CMF (IMHO) did promise but not
 deliver to the extent I had expected: A solid foundation for Content
 Management Systems.

just curious, what do you see as the problems with the cmf?

snip good stuff and removed cross-posting

cheers

kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: [ZODB-Dev] Replacing bobobase_modification_time

2002-01-08 Thread kapil thangavelu

On Tuesday 08 January 2002 06:47 am, Chris McDonough wrote:
  I think that a much better approach, if modification time is important
  to your application, is to store the application modification time in the
  object as a data attribute.

 It might be better to cause common Zope objects to do what Casey proposes
 (maybe via SimpleItem) as opposed to making folks keep app modtimes for
 those and as opposed to changing the semantics of
 bobobase_modification_time.  In Zope2, this would be achieved via a mixin
 named something like Modifiable mixed in to DTML Document, File, etc.

this sounds like a much better approach to me. the only question i have then, 
is how to hook modification times (as opposed to storage timestamps) without 
messing with Transaction.py?

cheers

kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: [Zope] [Bug] bobobase_modification_time unreliable to catalog

2002-01-07 Thread kapil thangavelu

On Monday 07 January 2002 06:20 am, Casey Duncan wrote:
 On Saturday 05 January 2002 08:15 pm, kapil thangavelu allegedly wrote:
  On Sunday 30 December 2001 08:00 pm, Casey Duncan wrote:
   This behavior is logical if unintuitive. I propose
   that we can kill two birds with one stone to fix this:
  
- Add a new method perhaps: getModificationTime() to
   the API of SimpleItem or even Persistent that returns
   the ZODB modification time or if the object has been
   changed, but not yet commited, the current date/time.
  
   - Deprecate bobobase_mod_time and perhaps even omit it
   entirely from Zope3.
  
   This will fix the aforementioned bug and get rid of an
   API anachronism.
  
   Thoughts?
 
  sounds good, i played around with an implementation to do the above. i'm
  not posting it here causes its inefficient, although i'm happy to email
  it to anyone who's interested. it basically added three methods.

 [snip details]

 For memory concerns, couldn't you just store the DateTime as a floating
 point number? This would incur just a small overhead to create a DateTime
 object when the value is looked up.

 I am interested in seeing this code. From my perspective it seems overly
 sophisticated. I'm interested how you derive the registration time in the
 first place.

your right, what i did was overly complex. i took your suggestions and 
simplified to the following two methods, which stores the txn registration 
time on the object as a float. it looks like an ok solution, imo. it doesn't 
do much for newly created persistent objects for which it falls through to 
the behavior of bobobase_modification_time and returns the current time.

in PersistentUtil class in lib/python/App/PersistentExtra.py new method

from Acquisition import aq_base
def getModificationTime(self):
ob = aq_base(self)
if hasattr(ob, '_p_changed') and ob._p_changed:
return DateTime(self._p_registration_time)
else: return self.bobobase_modification_time()

in Transaction class in lib/python/ZODB/Transaction.py altered register method

def register(self, object):
self._append(object)
object._p_registration_time = time.time()


cheers

kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: [Zope] [Bug] bobobase_modification_time unreliable to catalog

2002-01-06 Thread kapil thangavelu

On Sunday 30 December 2001 08:00 pm, Casey Duncan wrote:
 This behavior is logical if unintuitive. I propose
 that we can kill two birds with one stone to fix this:

  - Add a new method perhaps: getModificationTime() to
 the API of SimpleItem or even Persistent that returns
 the ZODB modification time or if the object has been
 changed, but not yet commited, the current date/time.

 - Deprecate bobobase_mod_time and perhaps even omit it
 entirely from Zope3.

 This will fix the aforementioned bug and get rid of an
 API anachronism.

 Thoughts?

sounds good, i played around with an implementation to do the above. i'm not 
posting it here causes its inefficient, although i'm happy to email it to 
anyone who's interested. it basically added three methods.

1. getModificationTime to App/PersistinentExtra.py 
2. is_registered(self,object) to ZODB/Transaction.py
3. get_registration_time(self, object) to ZODB/Transaction.py

add one data structure to Transaction.py, a registration_times dict.

when objects are registered they get a DateTime registered with them that 
gets added to registration_times based on their position within the 
registered objects list (_objects).  another solution might be a weak ref. 
keyed dict. so getModificationTime checks if the object is registered in the 
current transaction if it is it calls get_registration_time, else it falls 
through to bobobase_modification_time.

there are two inefficiencies one is memory because of DateTime for every 
registered object and two is computational from the lack of a uniform (across 
subclasses) hash function for persistent objects which results in traversal 
of the registered object list to identify if an object is registered or not 
(and to determine position to figure out the index into registration_times). 
a much better solution memory wise would have the transaction.py keep a 
DateTime for  its initialization and then have registered objects store 
registration times as deltas of that. i'm not sure what the better solution 
is in terms of the computational issue. but as is this solution doesn't seem 
scalable to me until the computational issues can be handled.

cheers

kapil


 -Casey

 --- Dieter Maurer [EMAIL PROTECTED] wrote:
  I just discovered that the value cataloged for
  bobobase_modification_time
  is often wrong:
 
 The cataloged value is not the time of the
  current modification
 but that of the previous modification.
 
 I expect that this is because
  bobobase_modification_time is updated
 when the transaction is commited while the values
  to be cataloged
 are determined before the commit.
 
  Do not trust the cataloged
  bobobase_modification_time!
 
 
  Dieter
 
  ___
  Zope maillist  -  [EMAIL PROTECTED]
  http://lists.zope.org/mailman/listinfo/zope
  **   No cross posts or HTML encoding!  **
  (Related lists -
 
  http://lists.zope.org/mailman/listinfo/zope-announce
   http://lists.zope.org/mailman/listinfo/zope-dev )

 __
 Do You Yahoo!?
 Send your FREE holiday greetings online!
 http://greetings.yahoo.com

 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] References, persistence, BTrees

2002-01-05 Thread kapil thangavelu

Hi jeffrey,

perhaps it might save you a bit of trouble. i've written a publish/subscribe 
event channel that seems to have must of the functionality listed below 
although it does use the techniques that you wanted to avoid. its at 
http://www.zope.org/Members/k_vertigo/Products/EventChannel

at the moment its purposefully a simple publish subscribe model with filters. 
object references are stored via physical path and resolved via 
unrestrictedTraverse. 

On Thursday 03 January 2002 04:49 pm, Jeffrey P Shell wrote:
 I'm experimenting with an event notification service based on a
 publish-subscribe model for some projects I'm working on.  When a
 subscription comes in, a 'Subscription' object is made, that
 basically looks like this:

 class Subscription(Base):
  def __init__(self, subscriber, eventType, filter=None):
  self.subscriber = subscriber
  self.eventType = eventType
  self.filter = filter

  def __hash__(self):
  return hash(self.subscriber)  \
 hash(self.eventType)  \
 hash(self.filter)

 'subscriber' is a reference to the subscribing object, and it's
 very likely to be to an object in the ZODB.  Is it wise to have
 more than one persistent reference to a single persistent object?
 I swear that I had once heard Jim say (vocally) that you could do
 references like this in the ZODB now.  I'm trying to avoid using
 Paths because objects have a tendency to move around[*], and I have
 performance concerns for a single event service object to have to
 call 'unrestrictedTraverse' to every subscriber.

yes, this a concern and depends on usage. i generally don't have many 
listeners to a particular event. when this has been an issue,  i instead 
chain event channels and stick events in an event queue, which periodically 
gets flushed from a zeo client script. currently i'm doing this for a 
subscription model which works well since the subscriptions that way get sent 
out all at once, instead of bombarding the end user with lots of emails.

 [*] (it's due to the annoyances with manage_beforeDelete() and
 friends that
 I'm writing this tool.)

 Second question: If I use the hash of the Subscription as a key, is
 there any advantages/disadvantages with using an IOBTree to hold
 Subscription objects instead of a PersistentMapping?

memory usage would probably be an advantage over large numbers of 
subscriptions, but i'm not qualifed to answer...


cheers

kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] A modest proposal: Replace medusa with Twisted

2001-10-11 Thread kapil thangavelu

On Thursday 11 October 2001 03:30 am, Itamar Shtull-Trauring wrote:
 kapil thangavelu wrote:
  twisted is GPL and zope is not gpl compatible and that does not appear to
  be changing despite some mention from zc about trying to achieve
  compatiblity.

 Twisted is LGPL, and it might be possible to license it under something
 that will work with ZPL. I don't think this will be an issue if it comes to
 it.

itamar,

thanks for the license clarification.

i didn't mean to suggest that its not a good idea to work on it.

i was hoping that someone from zc would give some sort of status update to 
paul's statements from http://aspn.activestate.com/ASPN/Mail/Message/622793
june.

kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] ZPL2.0

2001-10-11 Thread Kapil Thangavelu

 Only a little bit more arm twisting needs to be done
 in order for RMS to approve ZPL 2.0 as GPL
 compatable.  We're very close, it's just sometimes,
 tricky to get a straight answer when speaking in
 legal terms.

and there was much rejoicing:)

seriously, i'll buy a round for those involved who
show up at ipc10.

dealing with RMS is tricky period.

kapil



__
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] A modest proposal: Replace medusa with Twisted

2001-10-10 Thread kapil thangavelu

On Wednesday 10 October 2001 08:09 am, Michel Pelletier wrote:

 Just to throw out another idea, Amos has discussed with me in the past the
 idea of replacing medusa with Apache 2.0.  Compelling as many of Twisted's
 features may be, Apache 2.0 as far as i can tell supports many of them as
 well (except perhaps jython integration, which is a pipe dream anyway for
 Zope).  Apache has the upshot in that it is rock solid, tested by millions,
 trusted by even more, and no doubt one of the most actively developed
 peices of software there is.

 For ZC the upshots of 1) not needing to maintain it, and 2) it being a
 excellent marketing tool outweight many technical benifits that twisted may
 have that Apache doesn't (I'd like to know what the differences are,
 however).  For example, does twisted do URL rewriting?  proxy? 
 process/thread job control?

i'd never thought i'd see the day, open source software advocating the 
inclusion of other open source software because of marketing dictates.


 I'm not dismissing the idea, I'm just pointing out an alternative to
 Itamar's alternative.  ;)

my alternative to your alternative, is aolserver and mozilla. no mozilla 
isn't a webserver, but why should zope be either. 

cheers

kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] [ann] developer tools

2001-10-02 Thread kapil thangavelu


Developer Tools release

  ExtSearch/ExtIndex - Allows FS search from zope, integrates with swish++, 
includes a pluggable index and standalone version

  EventChannel - simple publish/subscribe system for zope with different 
channels and filters.

  SQLEngine - loads up sql methods from the fs, and provides a container for 
them, currently hardcoded to openacs's query xml syntax, but those who llike 
snakes should have no problem adjusting to other formats.

License: GPL

documentation on these varies, most integrate with the help system to
provide documentation.

download: http://www.zope.org/Members/k_vertigo

cheers

kapil thangavelu


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Web Services for Zope

2001-09-27 Thread kapil thangavelu

On Wednesday 26 September 2001 04:41 pm, Andy McKay wrote:

 trying-to-auto-generate-a-wsdl-from-my-product'ly yours

they're is a python script/product on ibm.com/developer that will automate 
much of the wsdl generation or you. its linked from one of uche's web 
services articles. its under the IPL (ibm pl).

hth

kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Web Services for Zope

2001-09-27 Thread kapil thangavelu

On Thursday 27 September 2001 08:15 am, Brian Lloyd wrote:
  Can I ask what the current status of the WebServices for Zope project is?
 
  http://dev.zope.org/Wikis/DevSite/Projects/WebServicesForZope/FrontPage
 
  Wiki says I had been shooting for something at the end of September, but
  that has been overtaken by events :( I'll be trying to work on this on an
  as-possible basis
 
  trying-to-auto-generate-a-wsdl-from-my-product'ly yours
  --
Andy McKay.

 Well... the status is that I'm trying to work on it on an
 as-possible basis :) The problem is that it hasn't been very
 possible for the last few weeks.


i've been very curious, what the plan is for attacking the no magic problem 
described on the wiki. my understanding is this isn't possible without 
altering the publishing process. i guess i was curious if the component based 
publisher that was talked about at ipc9 was ever going to see the light of 
day or if there was another strategy that would work as well.

curious,

kapil thangavelu

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] pluggable indexes and ranking

2001-09-14 Thread kapil thangavelu

i've hooked up some external indexing machinery to zcatalog 
via a pluggable index. i get backed ranked results and i'd like not 
to loose the ranking info, but i don't know how to return a result
set that preserves this information. any ideas?

-kapil 

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] exceptions on windows

2001-09-14 Thread kapil thangavelu

i've always been curious why zope on windows with 
a bundled python seems to have problems with finding
the standard lib exceptions. does anyone know why?

for example 

from exceptions import SyntaxError

class MySyntaxErr(SyntaxError):
pass

in a product generates an import error.

(i last noted this behavior on 2.2, haven't used windows since...)


thanks

-kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Using Zope-modules in Python

2000-10-18 Thread Kapil Thangavelu

Thomas Weholt wrote:
 
 Hi,
 
 I want to use some Zope-modules in plain Python, no web-stuff, namely ZODB
 and Persistence (maybe others too ). I've installed BeOpen Python 2.0 and
 Zope 2.2.2. I want to import the Zope-modules, but adding the C:\Program
 Files\WebSite\lib\python-folder to sys.path just doesn't cut it. I get an
 import error. Running on Windows 2000.
 
 Any tips, hints or guides wanted. Thanks!

a good place to start

http://starship.python.net/~amk/zodb/index.html

kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] MailHost Improvements

2000-10-09 Thread Kapil Thangavelu


There has been intermittent talk of improving mailhost's ability to
scale. i just wanted to solicit some comments to some ideas for
improving mail host performance. 

Stage I. Persistent Socket
1. make the smtp connection persistent
2. preface sending mail with a 'noop' operation to verify connection
status
3. overide __setstate__ to open connection

i'm not sure if this will yield any real world benefit but i like the
style better than opening a new connection for every new message.

Stage II. Transaction Aware
1. Store sent mail in a volatile 
2. on transaction commit begin (tpc_begin), send all mail, if error
abort transaction
3. reset volatile

again i'm not sure of real world performance, but the design seems
better and the added benefit that it will play nicely with the
transaction machinery and not send unesc. emails.


Stage III. Intelligent Q. aka the BulkMailHost

1. implement mailer thread / sole function to send mails from queue and
intelligently manage a outgoing queue and deferred queue.
2. implement extensions to sendmail tag for immediate sending of mail
which will wake/signal mailer thread after depositing into outgoing q.
extension options are

3. mailer thread on a timer, so it will wake on either a sendmail tag
with immeadiate extension or on timer expiration and send mail from
queue, messages with error due to connection or placed in deferred
queue. messages with undelivarable errors are either deleted or placed
in a deleted queue.

4. all queues are viewable and manageable from the management interface. 


obviously this makes the sendmail tag async to the message being sent.

i'm not sure if this something that really should be implemented in a
ZODB default file storage due to the high write nature of the system or
just dumped to the fs. again this seems questionable also because a
proper mta should be operating on a store and send principle
(qmail/postfix).

comments?

hmmm... looking through the source of the 2.2.2 mailhost i see a
scheduledSend method, anyone know what this is from/for?

Cheers

Kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




Re: [Zope-dev] Re: [Zope] Container Class questions

2000-10-08 Thread Kapil Thangavelu

Dieter Maurer wrote:
 
 Robin Becker writes:
   I would like to add properties in a property sheet, but cannot find a
   neat way to see the properties on the base object and on the
   propertySheet.
  
   So I would like my properties to show
   id
   title
  
   and the properties on my basic properties sheet.
  
   I can easily add properties directly to the object during the Thing_add
   and Thing_addForm and these appear on the properties tab for added
   objects.
  
   How do I get a tab for the property sheets?
 
 I am not sure, I understand precisely, what you want to reach.
 
 ZClass properties are managed on distinct property sheets.
 I do not know of a neat way to present (and change) properties
 from different property sheets (other than adapting the
 "manage_PropertiesForm" manually).


I wrote up some code (dated) to present generic forms for changing
zclass properties, code to follow. i generally use it just to get a fast
prototype for a system, example: picking a property sheet and harding
coding a link to the second method. yes this code does find base class
properties (including stuff like webdav, etc), or at least it did last
time i used it (era 2.1.6). 

hope this helps

Kapil


three methods

one to select a property sheet

one to edit a property

one to change a property sheet


1. edit_properties

dtml-var standard_html_header
centerbPlease Pick A Property Category/b/center
table align="center"
form action="edit_propertyCategory" method="POST"
trtd
SELECT name="PropertyCategory"
dtml-in "propertysheets.items()"
OPTION value="dtml-var sequence-key"dtml-var
sequence-key/OPTION
/dtml-in
/SELECT
/tr/td
trtdINPUT TYPE="SUBMIT" value="Edit Properties"/td/tr
/form
/table
dtml-var standard_html_footer

2. edit_PropertyCategory

dtml-var standard_html_header


dtml-if "REQUEST.has_key('PropertyCategory')"

dtml-in "propertysheets.items()"
dtml-let y=sequence-key

dtml-if "REQUEST.PropertyCategory==y"
dtml-let x=sequence-item

table border="1" align="center" cellspacing="0" cellpadding="4"
trth colspan="2" align="center"Edit dtml-var y
Properties/th/tr

form action="edit_propertiesChange" method="POST"
dtml-in "x.propertyItems()"
trtd
dtml-var sequence-key
/tdtd
input type="text" name="dtml-var sequence-key" value="dtml-var
sequence-item"
/td/tr
/dtml-in

trtd colspan="2" align="center"input type="SUBMIT" value="Change
Properties"/td/tr
input type=hidden name="PropertyCategory" value="dtml-var
PropertyCategory"
/form
/table
/dtml-let
/dtml-if

/dtml-let
/dtml-in

dtml-else
You have reached this page in error
/dtml-if

dtml-var standard_html_footer


3. edit_propertiesChange

dtml-var standard_html_header

dtml-if "REQUEST.has_key('PropertyCategory')"

dtml-in "propertysheets.items()"
dtml-let y=sequence-key

dtml-if "REQUEST.PropertyCategory==y"
dtml-let x=sequence-item
dtml-call "x.manage_changeProperties(REQUEST)"
dtml-var PropertyCategory Properties Changedbr
a href="dtml-var URL1"Back To Object/abr
a href="dtml-var URL2"Back To Container/a
/dtml-let
/dtml-if

/dtml-let
/dtml-in

dtml-else
You have reached this page in error
/dtml-if

dtml-var standard_html_footer

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] two-phase-commit question

2000-09-29 Thread Kapil Thangavelu

ZOPE_HOME/lib/python/Shared/DC/ZRDB/TM.py

Glancing over the Transaction TM mixin class... i noticed a line
commit=tpc_abort=tpc_begin

i can understand tpc_begin=commit, but the abort seems strange. 
if an abort happens in the two phase commit the equality doesn't 
make sense to me.

whats going on here? Is this meant to be overidden?

TIA

Kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] ZModules - A loaded gun

2000-09-28 Thread Kapil Thangavelu

i wrote up an interface to allow for module registration in the dtml
namespace, _

its got major caveats, but it might be useful for some.

at the moments its just a stop gap till the new python methods come
along. at the moment if just allows for people to write more code in
dtml:( or ttw python methods.

it might be useful to allow ttw developers access to some modules
without allowing them use of XXXpython_methods since the configuration
file that defines the imported modules resides on the FS.

an example use

dtml-let y="_.poplib.POP3('mail.earthlink.net')"
dtml-var "y.welcome"
dtml-var "y.user('kthangavelu')"
dtml-var "y.pass_('ipc9@longbeach')"
dtml-var "y.stat()"
/dtml-let

and the response

+OK EarthLink POP server (version: EL_3_10 ) at pop04.earthlink.net. 
[EMAIL PROTECTED]
+OK Password required for kthangavelu.
+OK kthangavelu has 0 messages (0 octets).
(0, 0)

personally i thinks it better to just pass the module off to a python
method
and let it do the work. real coding in dtml is heinous, maybe even a
crime against humanity.

how it works.

it reads a module configuration from the FS. fmt is currently

module_name: class_name, class_name


it tries to import the module and than place the module in the namespace
dict.
- usual python discovery rules apply (python_path, curdir)

it sets the magic key __allow__access_to_unprotected_subobjects=1 on all
imported modules.

it allows you to define classes in modules those you want to interact
with. defining those classes allows you to interact meaningfully with
instances otherwise zope's security policy will bump you because the
container doesn't define proper permissions or the magic key.

caveats:

it hasn't had much testing, i did it as proof of concept and because i
had an itch.

you can't accces any attributes of any object that doesn't define
__allow__access_to_unprotected_subobjects=1

an example where this is a pain, are getting filehandles back from
libraries,
like urllib.urlopen (note. urllib is not ts).

BE VERY VERY WARY OF THREAD SAFETY ISSUES

it might be very much like holding a loaded gun to your server;)

possible improvements:
allow for nested modules  classes
?


if people think this is useful enough, i'll package it up as a product.

installation.

create a directory in your products folder (mines called ZModules)

drop in the attached file.

write a configuration file 

restart zope

sample config file.

poplib:POP3
mimetypes


Cheers

Kapil

# DISTRIBUTED UNDER THE ZPL 
# Author [EMAIL PROTECTED]
# made for zope, www.zope.org

import App
import App.Common
import Globals
import os
from DocumentTemplate import DT_Util
from DocumentTemplate.DT_Util import d
from string import strip,split,replace

config_path=os.path.join(App.Common.package_home(globals()), 'zmodules.config')
 
fh = open(config_path)
modules_list=fh.readlines()

#print 'read config file'

counter = 0

for module in modules_list:
module = strip(module)
module = replace(module, '\012', '')
if len(module) = 1:
continue

module_config = split(module, ':')

if len(module_config)  1:
classes = split(module_config[1], ',')
else : classes = []

module = strip(module_config[0])
module_name = module[:]

try:
exec('import %s'%(module))
except:
continue

loaded_mod = eval(module)

s_classes = classes[:]
for class_name in classes:
class_name=strip(class_name)
if len(class_name) == 0: continue
try:
getattr(loaded_mod, 
class_name).__allow_access_to_unprotected_subobjects__=1
except:
s_classes.pop(s.index(s_classes))

d[module_name] = loaded_mod

loaded_mod.__allow_access_to_unprotected_subobjects__=1

print 'success: loaded module %s and classes %s'%(module_name, s_classes)















Re: [Zope-dev] RFC: page contracts

2000-08-31 Thread Kapil Thangavelu

Petru Paler wrote:
 
 Hi eveyone.
 
 While playing around with the development version of ACS (ArsDigita Community
 System), I noticed a very nice feature they introduced, namely page contracts.

I've been working with the ACS quite a bit lately (day-job:). its a nice
a system that offers a lot utility functions that would be nice to see
ported over to zope. most of its value lies in its data models. zope and
the acs have vastly different semantic models. i honestly see a lot of
the acs work as hacks around some of the problems of the programming
paradigms enforced by aolserver, that have little meaning in a system as
expressive and customizable as zopes(object publishing v. page
publishing  sql apps). 

with regards to the page_contract. 

IMO its def. useful from the standpoint of documentation and error
checking for your variables. implementing this as a folder of utility
methods and simply calling them from any doc that acquires from them,
passing in the request and optional args (props of doc?a nd this()?),
achieves the needed effect without much effort, and offering quite a bit
by way of customization. 

its also possible to do this as a python mixin class for objects. but it
would require a alot more work to do it transparently to the developer. 

Kapil

 In ACS, this means that every tcl page starts with a call to ad_page_contract.
 In the parameters passed, you specify:
- general page documentation (what it does)
- author(s)
- creation date (not needed for Zope since we have bobobase_modification_time)
- CVS ID (not quite applicable for Zope (yet?))
- the expected input variables (from forms) along with their default values
(where applicable) and types (having a couple of types like "integer" and "string"
predefined and an easy-to-use plugin system to add custom types)
- an optional validation block in which you can check the input data ranges
and validity (you can also make validation rules depend on each other so if
one fails, the rules which depend on it aren't tried)
- an optional custom error messages section (to use when one of the required
input variables is not there or does not match the format, or when a validation
block fails). If you don't provide this some reasonable defaults are provided.
 
 IMHO, such a feature would be very useful for Zope too. I find myself quite
 often doing input validation and error handling in DTML, which is (to say the
 least) painful.
 
 I would be interested to give a try at implementing this, but before starting
 I wanted to hear community's opinion on:
- whether this would be useful
- how this should be aproached (the two possibilities I have in mind until
now are either a separate manage tab for the page contract, and there a
HTML-based interface for building it, either a dtml-contract tag which
surrounds the page contract (written in python probably) and placed at the
top of DTML documents/methods).
 
 --
 Petru Paler, mailto:[EMAIL PROTECTED]
 http://www.ppetru.net - ICQ: 41817235
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




Re: [Zope-dev] New version of BTreeFolder

2000-08-29 Thread Kapil Thangavelu

Kapil Thangavelu wrote:
 
 Shane Hathaway wrote:

  BTW has anyone done any semi-formal speed tests?  It's rumored that a
  custom getattr in Python can cause a bit of a slowdown.  We could write
  a custom getattr in C to solve the problem.  But we don't want to do
  any premature optimization.
 
  Shane
 
 I'll work on some tests.
 
 Kapil


semi-formal test

i ran some basic tests comparing a btree folder against a folder. i'm
not sure about my testing methodology but here are the results. the test
code is at the end of this email. 

the first pair of numbers is a timed creation test for size xxx of DTML
Documents.

the second pair of numbers is a timed test for len(objectIds())

the third pair of numbers is a timed test for attribute access with a
call to 
int(dtmldoc.title_or_id()) # all the ids are stringed numbers

my test box is running mandrake 7.1 with 512 M ram, dual proc celerons
550s (oc'd)

some quick conclusions. the btree folder is slower on average for
creation by anywhere from 15-25% andt btree's __getattr is on average
almost twice as slow as the folder's getattr.


order folder followed by btreefolder

for size 100
0.0974419116974 :::0.126843929291
0.000378012657166 :::0.000354051589966
0.0101770162582 :::0.0186030864716

for size 100
0.0978569984436 :::0.125252962112
0.000376105308533 :::0.000353932380676
0.0101470947266 :::0.0185579061508

for size 500
0.52112698555 :::0.657492995262
0.00154399871826 :::0.00154197216034
0.0524510145187 :::0.0956329107285

for size 500
0.53660595417 :::0.714686989784
0.00154197216034 :::0.00157594680786
0.0532569885254 :::0.100463986397

for size 1000
1.11411702633 :::1.4010369
0.00302505493164 :::0.00306105613708
0.105547070503 :::0.193196058273

for size 1000
1.12388503551 :::1.58762395382
0.00370097160339 :::0.00381696224213
0.106634020805 :::0.194367051125

for size 2000
2.60056698322 :::3.20675897598
0.007483959198 :::0.00741696357727
0.216197967529 :::0.396993994713

for size 2000
2.64964604378 :::3.26421093941
0.0074850320816 :::0.00761103630066
0.214147925377 :::0.40997505188

for size 5000
9.50434195995 :::11.0002789497
0.0184400081635 :::0.018413901329
0.533676981926 :::0.997251987457

just to be fair i reversed the positions and
did a second set of runs with only 1 run per size as
the results were consistent with the first set.

for size 100
0.128319978714 :::0.10124707222
0.000413060188293 :::0.000383019447327
0.018816113472 :::0.0104240179062

for size 100
0.12813603878 :::0.101204037666
0.00040602684021 :::0.000380039215088
0.0188159942627 :::0.0105849504471

for size 500
0.681550979614 :::0.546862006187
0.00152194499969 :::0.00160706043243
0.0983099937439 :::0.0540620088577


for size 1000
1.47808301449 :::1.17385303974
0.00308799743652 :::0.00319290161133
0.197283029556 :::0.108732938766

for size 5000
11.1204429865 :::9.15097498894
0.015163064003 :::0.0150960683823
1.00954806805 :::0.535046935081


Despite this evidence. at size 5000, looking at the btreefolder contents
in the management screen was near instaneous while the folder took
almost a minute. based on the above evidence though that has more to do
with the interface than the underlying speed of the folder methods.

night.

Kapil

test code to follow.

external method


import time
import os
import Products.BTreeFolder

def btest(self, REQUEST, =None):
''' '''
if not : =100

results = []
bf = Products.BTreeFolder.BTreeFolder.BTreeFolder()
bf.id = 'btree_test_b'  
self._setObject(bf.id, bf)  

id = 'btree_test_f'
rf = self.manage_addFolder(id)

# creation test for completeness

stime = time.time()
for num in xrange():
self.btree_test_b.manage_addDTMLDocument(str(num))
etime = time.time()

result = etime-stime
#self.get_transaction().commit()

stime = time.time()
for num in xrange():
self.btree_test_f.manage_addDTMLDocument(str(num))
etime = time.time()

results.append(result, etime-stime)

# access test   
stime = time.time()
len(self.btree_test_b.objectIds())
etime = time.time() 
result = etime-stime

stime = time.time()
len(self.btree_test_f.objectIds())
etime = time.time()
results.append(result, etime-stime)

# iteration test
stime = time.time()
for oid, item in self.btree_test_b.objectItems():
int(item.title_or_id())
etime = time.time()
result=etime-stime

stime = time.time()
for oid, item in self.btree_test_f.objectItems():
int(item.title_or_id())
etime = time.time()
results.append(result, etime-stime)

return results

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts

Re: [Zope-dev] New version of BTreeFolder

2000-08-28 Thread Kapil Thangavelu

Shane Hathaway wrote:
 
 Hi gang,
 
 This version just fixes a bug with the folder contents tab on Windows.
 For some reason, on Windows 95 (and perhaps other platforms) the Python
 interpreter behaves differently enough that if you use a class
 attribute from a different module and put it in your own class, you may
 in fact be modifying its global context.  It's probably a bug in
 Python.  As a workaround, this version of BTreeFolders doesn't have the
 "details" tab anymore.
 
 http://www.zope.org/Members/hathawsh/BTreeFolder/BTreeFolder-0.1.1.tar.gz
 
 BTW has anyone done any semi-formal speed tests?  It's rumored that a
 custom getattr in Python can cause a bit of a slowdown.  We could write
 a custom getattr in C to solve the problem.  But we don't want to do
 any premature optimization.
 
 Shane

I'll work on some tests.

Kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




Re: [Zope-dev] Caching problems

2000-08-18 Thread Kapil Thangavelu

Bob Pepin wrote:
 
 On Wed, Aug 16, 2000 at 05:31:29PM +0100, Carlos Neves wrote:
  You directly change a nonpersistence participant object.
  As stated in
  http://www.python.org/workshops/2000-01/proceedings/papers/fulton/zodb3.html :
 [...]
  but mainly... RTFM ;-)
 
 Well, thanks, but too bad the only FM I've been able to find about Zope are
 those .py files in lib/python/...
 
 I spent a whole day looking for documentation on ZODB internals on zope.org and
 zdp.zope.org, without being able to find anything... how about adding that
 paper to the search engine on zope.org? Is there more documentation like that
 one out there?


a couple actually, not located so that you can find them but they exist

jim fulton's paper from the ipc8 (python conference) is excellent
reading material. 

http://www.zope.org/Members/jim/Info/IPC8/ZODB3News

also the uml models 

http://www.zope.org/Documentation/Developer/Models/ZODB/

and another excellent paper by andrew kuchling on zodb and ZEO

http://starship.python.net/crew/amk/python/writing/zodb-zeo.html

there is also a how-to...

Cheers 

Kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] Online Docs

2000-07-24 Thread Kapil Thangavelu

I've been playing around with the ACS a bit lately. Its got one feature
which i would desparately like to see in zope. namely that every ACS
server is self documenting with regards to all of its methods. to see it
in an action check out 
http://www.arsdigita.com/doc/procs

this documentation is generated on startup of the server for all
available functions which make a call to a function proc_doc.

i looked at the existing python code auto documentors and the one i saw
that looked the best was
http://www.lfw.org/python (at the bottom of the page)
for documenting live objects. it could use some modifiying to generate
zope objects which would get cataloged and also to include a
functions/modules source.

does anyone think that this would be a good resource to have in zope.
searchable docs for developers on their servers of all the Zope Internal
Python Code and the Code for all the installed Products?


Kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] Making ZClasses AutoForm Generate

2000-07-16 Thread Kapil Thangavelu

I was reading over on linuxworld about some of Nick's complaints against
zope. one of them was the lack of ZClasses being able to autogenerate
forms for their property sheets. i wrote up some dtml methods which do
just that, see

 http://lists.zope.org/pipermail/zope/2000-July/029325.html

(i would have cross-posted but i was expecting a spanish inquisition:)

any DC people want to comment about folding something akin to this into
Zope's ZClass Machinery.

Cheers

Kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] Building A MailMan Search Interface

2000-07-16 Thread Kapil Thangavelu

I've come across an itch. I'm tired of having to go through the mailing
archives to find what i need. The search interface at egroups, is a bit
slow and cumbersome. The one at ntlpd is much nicer, but i'd like to
have my own so i can point an archiver/search interface at any mailman
mailing list.

So i decided i'd like to make a generic mailman search interface in
zope. i've got a cronable retrieval script working that grabs archives.
the next step is pretty crucial and i thought i'd ask around for advice.

My question than becomes one of storage and parsing. I'm looking for
suggestions on how to do this in an efficient and speedy manner. I'm
willing to use linux/nix specific stuff if it helps performance.

options:
first question that applies to most of these approaches is whether to
store mails an individual items or in default format of the text
archive.

flat file:
this gives me a couple of parsing/searching options. like using grep or
the c regexp library or the camel library (from helix code's evolution)
any other options for this format?

downside, this introduces some minor hurdles with presentation. 

zodb - btree folder
for parsing/indexing this basically forces me to use zcatalog, which i
don't think will scale to the amount of raw text without lotsa of ram. i
could be wrong (i haven't gone through the Catalog code), but this is my
working understanding of it. 

if i store the emails as archives i could probably whip up a reasonably
speedy external method that would search through them.

one benefit will be the ease of the presentation logic. but this is
secondary to a speedy system.

rdbms (probably postgres - maybe mysql)
i'd prefer postgres since i'll probably be doing some other work with
it. but %like% is probably one of the most expensive operations you can
use on a db and its pretty limited in syntax. if i had a spare oracle
system than i'd drop it in a heartbeat and use Intertext Media jaunx for
searching. But i'd hate to tie this to a very expensive closed system.
mysql seems to excel at speed (perhaps because it was designed for it:)
but again the limitations of sql search syntax pop up. if anyone knows
of any good ways to search through text in a db i'd love to hear about
em.


right now, i'm leaning slightly towards a flat file storage, but i'd
love to hear some suggestions.

Cheers

Kapil

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] Pickling Error and Method Delegation

2000-07-11 Thread Kapil Thangavelu


What I am trying to do:
I am developing a python product that is has several composed 'helper'
classes. I am trying to setup a method delegation service to have
certain methods of the helper classes called directly on the container.
the helper methods are defined in a text list called external_api of the
helper classes.


The Problem:
The code below works fine if i call it after the object is already in
the zodb. I can call methods of the helper classes through the
container. if however i try to put the method in the containers __init__
method i get an error back from zope about a pickle error. traceback
below. If i remove this method from __init__ everything works fine
again. 

Question:
Whats going on? help...

Platform: Linux 2.2.16
  Zope 2.1.6


Code
*** the try/except is only so the method doesn't barf on helper classes
that
don't define an external api, there is no hidden error.

   def setup_user_object(self):
""" setup external api to be called on object """
# setups a method delegation service for the external api
# not the most elegant but the one that worked first
global AuthenticationManager, SessionManager, UserPreferences,
UserInfo
user_class_map = ( (SessionManager, "self.sm."), )

for user_class, user_obj_string in user_class_map:
try:
  for method in user_class.external_api:
  for key, item in user_class.__dict__.items():
  if key == method and type(item) ==
types.FunctionType:
 
self.__dict__[key]=eval(user_obj_string+key)
except:
pass

return self.__dict__.keys()

Traceback
Error Type: UnpickleableError
Error Value: Cannot pickle objects

Traceback (innermost last):
  File /home/ender/Zope-2.1.6-src/lib/python/ZPublisher/Publish.py, line
214, in publish_module
  File /home/ender/Zope-2.1.6-src/lib/python/ZPublisher/Publish.py, line
179, in publish
  File /home/ender/Zope-2.1.6-src/lib/python/Zope/__init__.py, line 202,
in zpublisher_exception_hook
  File /home/ender/Zope-2.1.6-src/lib/python/ZPublisher/Publish.py, line
169, in publish
  File /home/ender/Zope-2.1.6-src/lib/python/ZODB/Transaction.py, line
237, in commit
  File /home/ender/Zope-2.1.6-src/lib/python/ZODB/Connection.py, line
325, in commit
(Info: (('Products.SIN.UserObject', 'UserObject'),
'\000\000\000\000\000\000\001]', ''))
UnpickleableError: (see above)

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )