- Zope-Dev - Zope lists

CVS?
by Robin Becker 04 Aug '99

04 Aug '99

C:\Python\devel\Zope>set HOME=/xfer/ZOPE C:\Python\devel\Zope>cvs -d :pserver:anonymous@zope.org:/cvs-repository -z7 up -P C:\Python\devel\Zope> CVS.EXE [update aborted]: recv() from server zope.org: EOF -- Robin Becker

2 1

Several bugs in Zope 2 CVS to bounce
by Martijn Pieters 04 Aug '99

04 Aug '99

Hi all, On a interesting project I am working on right now, we use the latest CVS for a production machine (I know, big nono, but the parts we use are stable as far as I can tell, or otherwise kicked into working order.) I came across a few issues, I'd like to bounce around here before posting them to the CVS: - ZServer/Medusa is very picky about the request formats, and doesn't generate proper errors about them. For instance, if the request uses only LF for line-endings, instead of CRLF, nothing happens. I mean: really nothing. The request is dicarded, no exceptions are logged, nothing, nada. It took me about 2 hours to figure this one out. A 'HTTP/1.1 400 Bad Request' would have been helpful here. Medusa also cannot abide any extra spaces in de first request line, like: 'POST /purchase/check HTTP/1.0' (watch it, there are two spaces between 'check' and 'HTTP'). This time there is an exception logged, because the regular expression that tries to parse this line bounces. Again, at least a 'HTTP/1.0 500 Server Error' would have been helpful, but in this case should be another 400 Bad Request response. In my particular case, the requests are sent by a third party server, and the owners are willing to tweak their code, and I can teak Medusa. But maybe Medusa should be more flexible in accepting minimally malformed requests, by changing LF's to CRLF's and allowing for more whitespace in request headers. - MailHost objects are broken, I cannot add new ones: Traceback (innermost last): File /usr/people/sneek/src/Zope2/lib/python/ZPublisher/Publish.py, line 256, in publish_module File /usr/people/sneek/src/Zope2/lib/python/ZPublisher/Publish.py, line 145, in publish File /usr/people/sneek/src/Zope2/lib/python/ZPublisher/BaseRequest.py, line 311, in traverse File /usr/people/sneek/src/Zope2/lib/python/App/FactoryDispatcher.py, line 143, in __getattr__ KeyError: manage_addMailHost When I revert to the old __init__.py, or use an existing Mailhost object, and I use the sendmail tag, I get an attribute error, no such method named '__call--' (sorry, no traceback, haven't got the access right now). It happens when line 182 of SendMailTag.py is called: mhost=md[self.mailhost] The namespace object (md) is trying to call the mailhost). Maybe this should read: mhost=md.getitem(self.mailhost, call=0) -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------

2 2

Re: [Zope-dev] the birth of ZCommerce
by Josh Zeidner 04 Aug '99

04 Aug '99

>Accounting packages are just wierd. How companies use them are even >wierder. Getting a compnay (or their accoutants) to change accounting >systems (le alone learn any new software) is a lesson in futilalty. >Probally the best thing you can do is provide ways to export data, and >pray. >In other words this shouldn't be made a priority, although it would be a >nice sell. Thats is why we should offer an API and let the developers "hook" in whatever accounting software they want. > > > 3) many of the features in packages such as Intershop > > > >If you want to have some fun start the debate in the office wether you >should store your inventory in Zope or a SQL database. Clearly both >approaches have their merits but it all depends on the situation. >I have yet to see an off the shelf integrated e-commerece solution that >makes anyone happy yet. Possibly NEITHER! (put that in your pipe and smoke it). Maybe the inventory info can come from our accounting system? That would be a feature not really offered by any existing commerce package- what most ecommerce packages attempt to do is EVERYTHING. What the aim of this project should be is to offer a way to sell products that live in an existing system( such as Quicken or SAP ) and allow the process of marketing/retail to be automated through the net. *Anything* that has to do with accounting should be the domain of the accounting system. > >My current line of thingking on e-commerece in Zope would be to provide a >series of components, not necesaryily an integradted store. This seems like the natural OpenSource/Zope way to do stuff. >* Some form of shopping cart object - you are correct sir >* Inventory control objects that can categorize items for sale but can > come from different datasources ZODB, SQL, etc... - you forgot the exterior accounting system. >* Credit Card Processor object *cough Wampum Generator cough cough* >* And a way to do reporting (This makes my head hurt) - this could be taken care of by the accounting software. >Let the developers glue it all together. - thats what were here for. -Josh Zeidner Phylogenic Inc. _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com

5 5

Re: [Zope-dev] the birth of ZCommerce
by Christopher Petrilli 04 Aug '99

04 Aug '99

> The CyberCash libraries use encryption, so there might be that whole > Crypto/Export issue to worry about as well. It is currently unclear whether software which simply links with crypto is "export restricted" but it might be worth looking into this. If it is, then you'd better CYA :-) Not ruling has ever been made, but it might be worth restricting access anyway... I don't know that CyberCash accepts transactions outside the US anyway, so it wouldn't be much use to a non-US person. I love this field.... NOT. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli(a)digicool.com http://www.digicool.com

1 0

Re: [Zope-dev] the birth of ZCommerce
by Josh Zeidner 04 Aug '99

04 Aug '99

> >Most high end accounting packages would use a SQL backend, I would >presume. > Or Com/CORBA... >It's been my experince that alot of companies will have some POS (That's >point of sales) system and then have some other accounting system say >MAS90, QuickBooks, or some retched little thing still running under dos. >What I was thinking was just a MarketItems object (to steal from EMarket) >that can be placed anywhere in the zope DB that provides a solid api for >listing, adding, and removing inventory items. It can then be inherited >from so that it can pull from a SQL db, use MS Com to talk to Quicken if >possible, or pull information our of the stack of papers on my desk. > No fair! I thought of that first. :) > > > > > >* Credit Card Processor object *cough Wampum Generator cough cough* > > >* And a way to do reporting (This makes my head hurt) > > > > - this could be taken care of by the accounting software. > > >There again, not all accounting packages process credit cards. If you >check out the Wampum Generator (excuse me while I pat myself on the back) >at www.zope.org/Download/Contrib you'll find a CyberCash connector that I >just uploaded yesterday for Zope. >Of course it dosen't compile under >Windows yet, I don't have access to a windows compiler. are you distributing the source for Wampum? _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com

1 0

Strange ZServer problem
by Brian Lenihan 03 Aug '99

03 Aug '99

The CVS Zserver has been doing this since 2.0b1 was released: A page containing a long select list (400+ items) gets truncated while rendering the list. I have tried a bunch of different browsers on multiple platforms. Telnet to port 8080 works - I get the whole page. The ZServer which comes with 2.0b1 also works. I have two Linux Boxes, one Redhat 6.0 kernel 2.2.9 and one Debian 2.0 kernel 2.0.37. The Redhat box works and the Debian box doesn't. I have no idea what is wrong. A diff of the CVS ZServer and the b1 server does not show anything which looks significant which leads me to believe this is not really a ZServer problem. Anybody have any ideas?

1 0

Re: [Zope-dev] the birth of ZCommerce (fwd)
by Scott Robertson 03 Aug '99

03 Aug '99

> Just going to toss in my $1.50 w/inflation :-) > > > 1) integration with accounting packages such as Quicken > > Define an API, but don't specifically choose an accounting package. Deal > with what the "use cases" are, rather than what Quicken expects. Quicken is > nothing like what most companies use, with a full double-entry ledger system > >Accounting packages are just wierd. How companies use them are even >wierder. Getting a compnay (or their accoutants) to change accounting >systems (le alone learn any new software) is a lesson in futilalty. >Probally the best thing you can do is provide ways to export data, and >pray. >In other words this shouldn't be made a priority, although it would be a >nice sell. Ahhhboy, I've got to remember to spell check these things before I e-mail them out. I mean it's one thing for everybody to think I'm an idiot, but another thing entirely to write your IQ on your business card, sheeesh!

1 0

Re: [Zope-dev] the birth of ZCommerce
by Christopher Petrilli 03 Aug '99

03 Aug '99

Just going to toss in my $1.50 w/inflation :-) > 1) integration with accounting packages such as Quicken Define an API, but don't specifically choose an accounting package. Deal with what the "use cases" are, rather than what Quicken expects. Quicken is nothing like what most companies use, with a full double-entry ledger system > 2) secure transactions Ah, there's the rub, this is a much more complex thing to do than it first appears. SSL is easy, but dealing with storage of credit-card information, and more so, delivery of goods via electronic means, is much more complex. > 3) many of the features in packages such as Intershop The first thing to tackle is whether this is US only or not, if not, then your tax issues just went through the ceiling. (I've had to deploy 3-4 instances of Open Market and Netscape Commerce Server) Taxation alone can require a HUGE database to back it up to do it correctly. Just wanna make sure you know how big the box is before you open it. Having said that, I'd love to see something down this road. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli(a)digicool.com http://www.digicool.com

2 1

RE: [Zope] ANN: ZSybaseDA 1.0.1
by Michel Pelletier 03 Aug '99

03 Aug '99

> Um, correct me if I'm wrong, but doesn't Level 2 mean that > the adapter is > thread safe, and thus has to release the Python global > interpreter lock? > I've been skimming through the new ctsybase.c and I don't see > it doing this. > Ok it's not level 2, but 1.9. However, it is thread safe (it will work with Zope using multiple threads), it's just not concurrent while in the C code at this point. Like I said, there will be another release real soon now, I wanted to get this out because lots of people were asking for it. -Michel

1 0

Re: [Zope] ANN: ZSybaseDA 1.0.1
by Phillip J. Eby 03 Aug '99

03 Aug '99

At 11:04 AM 8/3/99 -0400, Michel Pelletier wrote: > >Here is the official ZSybaseDA. Currently, the ZSybaseDA is a level 2 >DA, meaning that it will work with a threaded Zope, but all transactions >with all other level 2 DAs are serialized in the transaction manager. >The ZSybaseDA REQUIRES Zope 2.0! Um, correct me if I'm wrong, but doesn't Level 2 mean that the adapter is thread safe, and thus has to release the Python global interpreter lock? I've been skimming through the new ctsybase.c and I don't see it doing this.

1 0