- Zope - Zope lists

attribute used to index PDFs?
by Garth B. 13 Dec '05

13 Dec '05

TextIndexNG 3.1.1 Zope 2.8.0 Python 2.3.5 What attribute should be specified when indexing PDFs? I've been using "data". Word docs are indexed properly, but the PDFs aren't. The PDFs are still found with the rest of the files, but the indexed content is not what I expected. To try narrow things down, I set up a seperate test Catalog with only two PDFs. The number of distinct values for indexing these PDFs is around 6600 (which seems a little high for two pdfs with a combined total of 3 pages). In the Catalog tab of my test ZCatalog, the PDFs are listed as type "Unknown". The content type of these PDFs are set to "application/pdf'". (In my other ZCatalog, the PDFs and Word docs are listed as type "File") This is an excerpt from the vocabulary for "f" in my test Catalog's index: ------------------------- f f+æq f0 f2ök f5ô f6 f7ëfü fa false fb8aad1ed82a2cc33e9feb68a3f323 fbt fc fd fdo fe fea feâà ff fg fgiëü fh fib filter filters firstchar fió fl flags flatedecode fm fmx fnaèh font fontbbox fontdescriptor fontfamily fontfile2 fontname fontstretch fontweight footlight format ------------------------- It looks as though the converter isn't doing its job, or the index isn't recognizing the files as PDFs I have manually run pdftotext at the command line with each of the PDFs to see if pdftotext is having trouble and it appears to output the textual content properly. The TextIndexNG Converters tab does recognize it. Do I have a misconfiguration somewhere? Thanks!

2 4

Simple User Folder Setup
by Infor Gates 13 Dec '05

13 Dec '05

Dear zopist I am having problems in setting up Simple User Folder. Error Message: Error Type: UnconfiguredException Error Value: Addition of users has not been configured I have googled around for an answer. However, there is very little info on it. My Configuration: Zope2.8.4 / Windows XP Pro / Postgresql I have copied all (addUser.pys, addUser.sql, editUser.pys editUser.sql, deleteUser.pys deleteUser.sql, getUserIds.pys, getUserIds.sql, getUserDetails.pys, getUserDetails.sql) into the /TEST/acl_users/Contents page as advised in README. Do anyone have similar experiences? Thank you. --------------------------------- Yahoo! Shopping Find Great Deals on Holiday Gifts at Yahoo! Shopping

3 4

Re: [ZOPE] XML-RPC within ZOPE
by Jan-Ole Esleben 12 Dec '05

12 Dec '05

Chris: the errors I get are always ConflictErrors without any usable tracebacks. I would like to give more information, but it really is very complex when you go a little deeper and would probably not be useful. I'll try to describe it a little better anyway: I have an Object that offers an interface for dispatching methods. It does so by deciding wether the method's object is on the local server or not, and depending on that, calls it via XML-RPC or via the ZOPE context (self). A remote ZOPE server cannot be part of a ZEO backend because there need to be several (hundred) self sustained servers that can act on their own when the connection to the others fails (which is likely rather than possible). But, as I just realised - in an internet context, isn't it possible that something like this could happen without even being part of a design? One ZOPE server's object, say, "LibraryManager", calls an object in another ZOPE server, say "UniversityLibrary", via XML-RPC (because it doesn't even know it's ZOPE). It asks it for a book. The University Library doesn't have it, but it has a service that looks in all the libraries it knows and returns any found occurences. Thus, at some point during that call, it asks the first server's LibraryManager about the book - again, not even knowing that it is a ZOPE server, via XML-RPC. Should this work, and where does it differ from what I'm doing? > > The problem is that it isn't my design, and the design is part of a > > contract. I can't really do anything about that (the major problem is > > that there will be SOAP components that might even need to be > > transparently integrated - which completely excludes ZEO). > Why do you think that? ZEO is simply a single point of persistence for > a group of Zope Application Servers. But what if I don't know which components are ZOPE, and components can be transparently exchanged? Ole

1 1

Re: [Zope] Hooks for methods other than GET/POST on port 80?
by Chris Withers 12 Dec '05

12 Dec '05

(please keep the list CC'ed in) Roman Susi wrote: >> What do you mean by freezes? how did you cause this to happen? > > Surely, this is not only a bug but a security issue leading to DOS > attack, IMHO. Well, it's a pretty weird use case from what I can see... > >> >>> Traceback (most recent call last): >>> File "/usr/local/lib/python2.3/logging/__init__.py", line 674, in emit >>> msg = self.format(record) >>> File "/usr/local/lib/python2.3/logging/__init__.py", line 567, in >>> format >>> return fmt.format(record) >>> File "/usr/local/lib/python2.3/logging/__init__.py", line 369, in >>> format >>> s = s + self.formatException(record.exc_info) >>> File "/usr/local/lib/python2.3/logging/__init__.py", line 342, in >>> formatException >>> traceback.print_exception(ei[0], ei[1], ei[2], None, sio) >>> File "/usr/local/lib/python2.3/traceback.py", line 123, in >>> print_exception >>> print_tb(tb, limit, file) >>> File "/usr/local/lib/python2.3/traceback.py", line 68, in print_tb >>> line = linecache.getline(filename, lineno) >>> File "/usr/local/lib/python2.3/linecache.py", line 14, in getline >>> lines = getlines(filename) >>> RuntimeError: maximum recursion depth exceeded >> >> We need more of the traceback, there is no repeating part here so it's >> impossible to see what's causing the infinite recursion... >> > I am not sure how to get the whole traceback... Well, where did you see the above? > Chris, could you put this into Zope issue tracker (with security tick as > I do not want to make this info public right now)? > (I've tried but I do not have an account there..) No, there's nothing stopping you registering at zope.org and doing this yourself. Furhtermore, I'd guess this is likely a bug in your code and nothing to do with Zope ;-) (of course, I could be wrong on that, but I haven't seen any evidence yet) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

3 10

Re: [Zope] XML-RPC within ZOPE
by Jan-Ole Esleben 12 Dec '05

12 Dec '05

The problem is that it isn't my design, and the design is part of a contract. I can't really do anything about that (the major problem is that there will be SOAP components that might even need to be transparently integrated - which completely excludes ZEO). I tried doing my own commits, but it doesn't work, it just bombs earlier (no matter where I do them). I really don't know why, my only guess is that something about the transaction management breaks terribly when you go back and forth between objects without them being able to track it. Only I cannot figure out what. It is not possible to do _really_ explicit transaction management with ZODB, is it? Ole 2005/12/12, Alan Milligan <alan(a)balclutha.org>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jan-Ole Esleben wrote: > > OK, the following is the case: > > > > The setup is for functions dispatching either locally or via XML-RPC. > > At the moment, the mechanism I use is to detect locality is flawed and > > thus doesn't work well. So I have local XML-RPC calls where I could > > have global ones. But. > > > > 1. I need that possibility for testing the XML-RPC setup. I cannot set > > up multiple instances for every cheap test. At least I shouldn't have > > to. The very important reason, however, is: > > 2. This is a generic call dispatcher. It is used, for example, for > > object name resolution in a widely deployed system. So, what could > > happen and couldn't happen locally is this: > > Zope isn't CORBA. ZEO is the correct way to scale/cluster Zope's. > > > > > 1. Server1 dispatcher calls, via XML-RPC, Server2. > > 2. Server2 dispatcher calls Server1, which does something locally > > (same communication management object as the dispatcher, maybe another > > local call) and then returns > > > > This is the same problem spread out over two servers, where locality > > isn't possible anymore. The call from Server1 to Server2 must be made > > via XML-RPC and I cannot exclude Server2 calling Server1 back. > > If you really must architect your solution this way, then you are going > to have to do your own transaction management. Your 'local' calls need > to do explicit commit() calls and you're going to have to reread > 'tainted' objects. > > Again, it will take you half an hour to modify your design instead of > half a year to get all the bugs out of your implementation. > > Alan > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFDnN2ACfroLk4EZpkRAkQ7AJ4rTWpmldRq1GoPGIV8r0CT7+VPJwCZAbKB > 5PBuLd5sJgh7QZe1ey8lZ9g= > =3TrG > -----END PGP SIGNATURE----- >

2 1

Re: [Zope] zdsock
by John Poltorak 12 Dec '05

12 Dec '05

On Sun, Dec 04, 2005 at 11:32:15AM +0100, Andreas Jung wrote: > WHY? Because 'zdsock' is not an acceptable name. I am running on OS/2 and the path name must start with '\\socket\\'. > --On 4. Dezember 2005 10:26:03 +0000 John Poltorak <jp(a)warpix.org> wrote: > > > On Sun, Dec 04, 2005 at 11:13:29AM +0100, Andreas Jung wrote: > >> > >> > >> > > >> > At the top of sample.conf it says > >> > > >> ># Sample config file for zdctl.py and zdrun.py (which share a schema). > >> > > >> > This sounds like something other than zope.conf. > >> > > >> > >> Is there a real need for you to touch the configuration. Also as very > >> advanced Zope user I've never had the need to touch this configuration > >> for any reason. So what are your reasons? > > > > I need to change the name of the socket. > > > >> > >> -aj > > > > -- > > John -- John

4 16

Re: [Zope] XML-RPC within ZOPE
by Jan-Ole Esleben 12 Dec '05

12 Dec '05

OK, the following is the case: The setup is for functions dispatching either locally or via XML-RPC. At the moment, the mechanism I use is to detect locality is flawed and thus doesn't work well. So I have local XML-RPC calls where I could have global ones. But. 1. I need that possibility for testing the XML-RPC setup. I cannot set up multiple instances for every cheap test. At least I shouldn't have to. The very important reason, however, is: 2. This is a generic call dispatcher. It is used, for example, for object name resolution in a widely deployed system. So, what could happen and couldn't happen locally is this: 1. Server1 dispatcher calls, via XML-RPC, Server2. 2. Server2 dispatcher calls Server1, which does something locally (same communication management object as the dispatcher, maybe another local call) and then returns This is the same problem spread out over two servers, where locality isn't possible anymore. The call from Server1 to Server2 must be made via XML-RPC and I cannot exclude Server2 calling Server1 back. Does this make it a little more of a real problem? Ole 2005/12/12, Alan Milligan <alan(a)balclutha.org>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jan-Ole Esleben wrote: > >>It really *is* in your interests to ensure a single request completes > >>all your functional requirements ;) > > > > > > That's not possible unfortunately. The design of the system is rather > > complex, and unalterable in this respect. However, it is not true that > > it is usually possible to fulfil this requirement. What of programs > > running on an operating system that call other programs via that > > operating system? > > > > I don't believe you. > > You have a client application calling your Zope server's bla() > function. It can do this either by HTTP or XML-RPC by choosing the > appropriate Content-Type. > > You've chosen to implement this interface by making other XML-RPC calls > to the same server to complete the task. This is both unnecessary and > bad. Unnecessary because you're doing an RPC when you've got all you > need in local memory. This is bad because you're introducing the > additional overhead of setting up said RPC. Worse, you're now > responsible for your own transaction management because you've split the > task across multiple ZODB connections. > > You need to think about the *correct* way to write your bla() function. > In doing this, you want to be able to take advantage of the automatic > rollback facilities of Zope by keeping all of this in one transaction, > which will also avoid your initial problem of conflict errors. > > Alan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFDnNZcCfroLk4EZpkRArTDAJ96TGwDy047D09jkmRNbGyD7e+3QgCg0aNZ > lLo0znXi4qvXr5j4SseH2k8= > =hu4V > -----END PGP SIGNATURE----- >

1 0

Re: [Zope] XML-RPC within ZOPE
by Jan-Ole Esleben 12 Dec '05

12 Dec '05

> It really *is* in your interests to ensure a single request completes > all your functional requirements ;) That's not possible unfortunately. The design of the system is rather complex, and unalterable in this respect. However, it is not true that it is usually possible to fulfil this requirement. What of programs running on an operating system that call other programs via that operating system? Given that that is a requirement that needs to be met, do I have any options? Ole

1 0

Re: live dtml updating?
by Rich Harley 11 Dec '05

11 Dec '05

On Sunday 11 December 2005 22:30, you wrote: > > Hi all > > > > Sorry if this is not a specific zope question but I'm confident someone > > will be able to help me with the following. > > > > I have an input form on a webpage and below it a table which pulls out of > > a database. The column headers in the table relate to the input form in > > that I want whatever the user types into the input box for the correct > > column to be highlighted in bold. So say, for example I had two columns A > > and B I want column B to be highlighted bold when the user types 'b' into > > the input box > > at > > > the top. How can I do this? > > Rich -- www.horsey.tk

3 3

Zwiki contributor policy update
by Simon Michael 11 Dec '05

11 Dec '05

Hi all! I'm slightly burned out and bored with certain areas of Zope 2 Zwiki development. I think the product will provide some value for a while yet, and it's not too late to shake things up and make a bigger splash. If we don't do this during the period of Zwiki & Zope 2's relevance, our good work will bring less benefit than it might have. So I'm putting out a call for help. I'd really like to see more people take on development of Zwiki. What are the roadblocks - of my making, and otherwise - to a more active Zwiki developer community ? For one thing I needed to nail down some copyright/license issues more explicitly, to make contributing and accepting contributions more of a no-brainer. Here's my latest thinking: LICENSE Much Zope code uses the ZPL. We want to maximize code sharing and participation with the whole Zope community. Much of the rest of the FOSS world uses the GPL, and the same goes for them. Dual GPL/ZPL licensing may seem a good option, but I'm convinced it's not worth the added complexity, legal uncertainty and fragmentation; either straight GPL or straight ZPL is preferable. GPL is the mainstream license for the future IMHO, I think it's still the best option, and I have no plan to leave it. Also I think we should adopt GPLv3? <http://zwiki.org/PolicyAnnouncementDraft/createform?page=GPLv3> when it's ready. That said, there's now clear policy allowing non-GPL code to be added to Zwiki if necessary (below). Also I remain open to license exemption requests from Zope developers. COPYRIGHT I no longer think the single copyright holder policy is best for this project, and I'm going to drop it. I am changing the main repo's policy to multiple copyright holders (& allowing multiple licenses), with the simple condition that the overall project manager is assigned the right to relicense to newer license versions. The powerful darcs revision control system (together with new CONTRIBUTORS list) should help us to keep track of copyright & licensing status and even remove problematic commits later if needed. CONTRIBUTOR'S AGREEMENT To ensure that everyone gets proper credit for their work; a clear audit trail and legal status for the project; and that the project can remain license-compatible with other free & open-source software in future, I have added a very simple contributor agreement/contributor list: http://zwiki.org/repos/ZWiki/CONTRIBUTORS.txt . All Zwiki contributors should read and consider signing this file, to help us meet these goals. You can follow this easy procedure to add your name to the glorious list: (install darcs if needed, see http://darcs.net/DarcsWiki/CategoryBinaries) darcs get --partial http://zwiki.org/repos/ZWiki cd ZWiki echo "- Your Name <your@email>" >>CONTRIBUTORS.txt darcs record -a -m"signed it" CONTRIBUTORS.txt (enter your name & email address again) darcs send This will become the authoritative list of code committers (at least), and I'll be working to make sure all of you are listed properly. Many have donated their time and creativity over the years - this list will make that clearer. All comments, help and other ideas welcome. And I hope to see some of you online or off. Happy holidays, and thanks -Simon

1 0