pywrapper-devel Mailing List for pywrapper (Page 5)
Status: Alpha
Brought to you by:
jatorre
Menu
▾
▴
pywrapper-devel — PyWrapper Developers mailing list
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
(10) |
Apr
|
May
(4) |
Jun
|
Jul
(40) |
Aug
(20) |
Sep
|
Oct
(10) |
Nov
(112) |
Dec
(18) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(8) |
Feb
|
Mar
|
Apr
(6) |
May
(13) |
Jun
(12) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(3) |
| 2008 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(3) |
Jun
(3) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <m.d...@BG...> - 2006-11-20 14:57:52
|
Hi, I am going to roll-back the wiki and installer scripts again to use port = 80 explicitly with svn commands from the terminal. The default port for = the svn protocol (which we are using) is 3690. So normally if you don't = specify any port the client should therefore use this port which is = wrong in our case.=20 In general one should use svn://svn.pywrapper.org:80/pywrapper unless = you have some proxies in between that do something mysterious. If it = fails, try without port 80. Markus > -----Original Message----- > From: pyw...@li...=20 > [mailto:pyw...@li...] On=20 > Behalf Of Peter Brewer > Sent: Mittwoch, 15. November 2006 18:30 > To: PyWrapper Developers mailing list > Subject: Re: [PyWrapper-devel] SVN Server >=20 >=20 > Humm.... >=20 > The problem must be our dreaded proxy server as I checked out=20 > PyWrapper=20 > fine on my laptop from outside the University last week. =20 > I've set all=20 > the normal proxy settings in the svn servers file but still no luck. =20 > Could it be because the PyWrapper SVN server is running on=20 > port 80? Has=20 > anyone else checked out successfully from behind a proxy?=20 >=20 > In the mean time I'll continue googling... >=20 > Peter >=20 |
|
From: Skofic A. M. (IPGRI) <m.s...@cg...> - 2006-11-20 13:25:38
|
I have tried to register a service in the IRRI registry, these are the parameters: End-point: http://cropwiki.irri.org/cgi-bin/MOBY-Central.pl Namespace: http://cropwiki.irri.org/MOBY/Central TAPIR returns the following error: Sorry, the service was not registred. The BioMOBY end point and namespace you have configured is not accessible. Are you sure this is a MOBY registry? What should I ask the IRRI people to solve the problem? I took the end-point and namespace from Dashboard, so it should be the correct information. By the way, I registered in their registry the TapirProvider service type. On Nov 20, 2006, at 10:45 , Javier de la Torre wrote: > Aghh, > > Thats because your old biomoby-settings file is not now up to date, > the services now in the config file have information about which > registry was used to register them but in your case because your > files are not updated, see the empty parethesys close to the > service name? the configtool does not know from where to doregister. > > If you want send me your biomoby-settings file and I will update it > accordely to the new version, then it will work. > > Javi. > > On 20/11/2006, at 10:35, Skofic A. Milko (IPGRI) wrote: > >> I am trying now with the changes. I had to update the moby >> configuration files to get into the user interface. >> >> First of all, I think that having one registry per data source is >> fine, if you need to register a service in different registries >> why not create a new data source and point to the other registry >> from there? The need to be able to select a registry is crucial >> for us, but once it is selected I don't think it should change. >> >> Now for the tests, I wanted to deregister the current services >> before changing registry, but it doesn't allow me to do so, it >> says that: >> >> BioMOBY Settings >> >> The service <b>getTaxaOfBoundingBox</b> could not be deregistered. >> Is the central MOBY registry accesible? >> >> 1) Services you are already publishing and registry where you >> registered them: >> >> TestServiceABCD ()Deregister >> getTaxaOfBoundingBox ()Deregister >> Deregister all >> 2) Considering the mappings that you already have done, you could >> be publishing: >> >> There are no other services available to register >> General settings >> BioMOBY registry end point >> >> BioMOBY registry Namespace >> >> bmttsUrl >> >> ServiceNs >> >> AuthURI >> >> ContactEmail >> >> databaseName >> >> >> Save >> >> >> It looks as if it cannot communicate with the registry end point >> (I left the Canada one). >> >> During the startup process of TAPIR I got a strange message: >> >> ERROR! from pywrapper: REQ_READ_MODEL_FAILED:::The requested model >> TCS 1.01 could not be read. Reason: Could not access external >> model component(s) >> Traceback (most recent call last): >> File "/Library/WebServer/Services/pywrapper/lib/biocase/ >> pywrapper/model.py", line 252, in __readFile__ >> self.parser.parse( file(filename) ) >> File "/Library/WebServer/Services/pywrapper/tools/python/lib/ >> python2.4/site-packages/_xmlplus/sax/expatreader.py", line 109, in >> parse >> xmlreader.IncrementalParser.parse(self, source) >> File "/Library/WebServer/Services/pywrapper/tools/python/lib/ >> python2.4/site-packages/_xmlplus/sax/xmlreader.py", line 123, in >> parse >> self.feed(buffer) >> File "/Library/WebServer/Services/pywrapper/tools/python/lib/ >> python2.4/site-packages/_xmlplus/sax/expatreader.py", line 216, in >> feed >> self._parser.Parse(data, isFinal) >> File "/Library/WebServer/Services/pywrapper/tools/python/lib/ >> python2.4/site-packages/_xmlplus/sax/expatreader.py", line 353, in >> start_element_ns >> AttributesNSImpl(newattrs, qnames)) >> File "/Library/WebServer/Services/pywrapper/lib/biocase/tools/ >> saxhandler_extended.py", line 100, in startElementNS >> self.startSimpleElement(ns, localname.lower(), attributes) >> File "/Library/WebServer/Services/pywrapper/lib/biocase/ >> pywrapper/model_handler.py", line 69, in startSimpleElement >> parser.parse(attrs.get('location')) >> File "/Library/WebServer/Services/pywrapper/tools/python/lib/ >> python2.4/site-packages/_xmlplus/sax/expatreader.py", line 103, in >> parse >> source = saxutils.prepare_input_source(source) >> File "/Library/WebServer/Services/pywrapper/tools/python/lib/ >> python2.4/site-packages/_xmlplus/sax/saxutils.py", line 523, in >> prepare_input_source >> f = urllib2.urlopen(source.getSystemId()) >> File "/Library/WebServer/Services/pywrapper/tools/python/lib/ >> python2.4/urllib2.py", line 130, in urlopen >> return _opener.open(url, data) >> File "/Library/WebServer/Services/pywrapper/tools/python/lib/ >> python2.4/urllib2.py", line 358, in open >> response = self._open(req, data) >> File "/Library/WebServer/Services/pywrapper/tools/python/lib/ >> python2.4/urllib2.py", line 376, in _open >> '_open', req) >> File "/Library/WebServer/Services/pywrapper/tools/python/lib/ >> python2.4/urllib2.py", line 337, in _call_chain >> result = func(*args) >> File "/Library/WebServer/Services/pywrapper/tools/python/lib/ >> python2.4/urllib2.py", line 1021, in http_open >> return self.do_open(httplib.HTTPConnection, req) >> File "/Library/WebServer/Services/pywrapper/tools/python/lib/ >> python2.4/urllib2.py", line 996, in do_open >> raise URLError(err) >> URLError: <urlopen error (60, 'Operation timed out')> >> WARNING! from pywrapper: The model http://rs.tdwg.org/tapir/cs/ >> tcs1.01/model/tcs101.xml could not be loaded. It might be corrupt. >> >> It looks like the TCS model is corrupt. >> >> Let me know if you need other information. >> >> Ciao! >> >> Milko >> >> On Nov 19, 2006, at 20:11 , Javier de la Torre wrote: >> >>> Hi Milko, >>> >>> Ok. I have implemented some sort of multiple biomoby registry >>> awareness in pywrapper. >>> >>> Now in the MOBY tab there are two new fields in the General >>> Settings: >>> >>> "BioMOBY registry end point" and "BioMOBY registry Namespace". >>> >>> This let you choose the registry you want to use. This >>> information is saved as a general setting for this datasource. >>> But preparing the work for the future now when you register a >>> service the information of the end point and the namespace is >>> stored in the service on the config files, thats allowing the >>> same service to be register in multiple biomoby registries. >>> >>> When you click on register a service the configtool uses the >>> registry specify at this moment on the general settings, but when >>> you click on Deregister it uses the registry that was used for >>> registration. >>> >>> By default I have left configured the CENTRAL MOBY REGISTRY in >>> Canada. Milko, if you think more people are going to use the IRRI >>> one I can change it, give me the end point and ns and I change it >>> on the default config file so that new installations will appear >>> with this. >>> >>> There are some limitations still that I hope will not prevent us >>> from delopying right now: >>> >>> -Althought the config tool stores the info on the registry that >>> was used for registering a service, the interface will still not >>> offer you the possibility to register the same service in >>> multiple registries. If the config tool detects that a certain >>> service has been already registered in a registry is not offered >>> as a potential service. In the config files is still possible to >>> configure the same service in multiple registries, altought you >>> would have to manually register them using Dashboard or something >>> like this... >>> >>> -The BMTTS file gives pywrapper a list of service templates, but >>> it does not tell you for what registry this templates are >>> designed. Different registries have different data types. So a >>> service template for the IRRI server does not necessarily have to >>> work with the Central one in Canada... Therefore is needed that >>> the BMTTS stores information about to which registry a certain >>> template was designed. Then the config tool should read this info >>> and react according to this... >>> >>> I have only tried it with the central moby registry in Canada, >>> but I suppose it should work with others. I havent tried because >>> I dont have the url of the IRRI registry and the >>> getCoordinatesOfTaxon service template will probably not work >>> with the data types there... Could you try Milko with yours? >>> >>> >>> It is commited now. >>> >>> Javi. >> > |
|
From: <m.d...@BG...> - 2006-11-20 09:52:55
|
Ram=F3n, I am not sure what the reason is in your case. I would imagine it has to do with the choices. If more than one branch = of a choce has mappings, Pywrapper tries to use the first one. In your = case that's the "Text" one, for example SpeciesRecordCollaborators/Text. = Could you try the model using sequences instead of chocies for a test? = And can you send us the debug.log file too for your requests? By the way, in your models mapping section you have mapped the model = structure to concepts defined by the same schema. We call this a = canonical model and you can make your life easier by using the = automapping=3D"true" flag in the mapping section. Just like the = canonical abcd model: = http://rs.tdwg.org/tapir/cs/abcd2.06/model/abcd206.xml It maps every node of the schema to itself, using the namespace of the = schema to create qualified concept ids. Markus > -----Original Message----- > From: tdw...@li...=20 > [mailto:tdw...@li...] On Behalf Of=20 > Renato De Giovanni > Sent: Freitag, 17. November 2006 19:14 > To: tdw...@li... > Subject: Re: [tdwg-tapir] Problem with Tapir and Outputmodel. >=20 >=20 > Hi Ram=F3n, >=20 > Two quick comments about the output model: >=20 > * At a first glance I thought there were still two mandatory=20 > elements: >=20 > /Species/Record/RecordInformation/TargetAudience/Audience > /Species/Record/RecordInformation/TargetAudience/Text >=20 > But now I see that they are inside a choice of an optional element,=20 > so in theory this should not be a problem. >=20 > * It's curious that you mapped complex elements like Species, Record,=20 > DataSource and others. Some are just grouping elements, others can be=20 > seen as related to class instances. But as far as I know PyWrapper=20 > doesn't handle this kind of mapping. >=20 > Not sure if these things can help finding out the reasons for not=20 > getting all expected results...=20 >=20 > Regards, > -- > Renato >=20 > On 17 Nov 2006 at 18:26, Ram=F3n P=E9rez wrote: >=20 > > Hi Markus and Renato, > >=20 > > Thanks very much for yours response. I have tried your=20 > suggestions but=20 > > i > > don't resolve the problem. > >=20 > > I have simplified the outputmodel and I have changed all=20 > attribute to > > optional. > >=20 > > With the outputmodelpcore2.xml the response is: > >=20 > > <RecordInformation>=20 > > <GlobalUniqueIdentifier>GUIDS-1</GlobalUniqueIdentifier> > > <SpeciesRecordID>1--1.1</SpeciesRecordID> > > <Language>latin1</Language> > > <SpeciesRecordAuthors> > > <SpeciesRecordAutor> > > <Text>Alexander Rojas A.</Text> > > </SpeciesRecordAutor> > > <SpeciesRecordAutor> > > <Text>Jose Gonzalez</Text> > > </SpeciesRecordAutor> > > </SpeciesRecordAuthors> > > <SpeciesRecordCollaborators> > > <SpeciesRecordCollaborator> > > <FirstName>Francisco</FirstName> > > <LastName>Morales</LastName> > > </SpeciesRecordCollaborator> > > </SpeciesRecordCollaborators>=20 > > <PublicationDate>2006-10-09</PublicationDate> > > <DateLastModified>2006-10-09</DateLastModified> > > <TargetAudience> > > <Text>1</Text> > > </TargetAudience> > > <Version>2.1</Version> > > </RecordInformation> > >=20 > > With the outputmodelpcore3.xml, the response is: > >=20 > >=20 > > <RecordInformation>=20 > > <GlobalUniqueIdentifier>GUIDS-1</GlobalUniqueIdentifier> > > <SpeciesRecordID>1--1.1</SpeciesRecordID> > > <Language>latin1</Language>=20 > > <PublicationDate>2006-10-09</PublicationDate> > > <DateLastModified>2006-10-09</DateLastModified> > > <TargetAudience> > > <Text>1</Text> > > </TargetAudience> > > <Version>2.1</Version> > > </RecordInformation> > >=20 > > The pywrapper deletes the SpeciesRecordAuthors and > > SpeciesRecordCollaborators nodes. This is the important=20 > information in=20 > > the diagnostic: > >=20 > > <diagnostic time=3D"2006-11-17T18:24:45.32" level=3D"warn"> > > The element > >=20 > /Species/Record/RecordInformation/SpeciesRecordCollaborators/S > peciesRecordCollaborator/Record=20 > > was limited 3 times. Some node instances have been lost. > > </diagnostic> > > - > > <diagnostic time=3D"2006-11-17T18:24:45.32" level=3D"warn"> > > The element=20 > >=20 > /Species/Record/RecordInformation/SpeciesRecordAuthors/Species > RecordAutor/Text=20 > > was limited 5 times. Some node instances have been lost. > > </diagnostic> > >=20 > > I attach a picture with the query result in the database. It doesn't > > exist null values. > >=20 > > Thanks for all, > >=20 > > Ram=F3n. >=20 > _______________________________________________ > tdwg-tapir mailing list > tdw...@li...=20 > http://lists.tdwg.org/mailman/listinfo/tdwg-> tapir >=20 |
|
From: Javier de la T. <ja...@gm...> - 2006-11-20 09:46:17
|
Aghh,
Thats because your old biomoby-settings file is not now up to date,
the services now in the config file have information about which
registry was used to register them but in your case because your
files are not updated, see the empty parethesys close to the service
name? the configtool does not know from where to doregister.
If you want send me your biomoby-settings file and I will update it
accordely to the new version, then it will work.
Javi.
On 20/11/2006, at 10:35, Skofic A. Milko (IPGRI) wrote:
> I am trying now with the changes. I had to update the moby
> configuration files to get into the user interface.
>
> First of all, I think that having one registry per data source is
> fine, if you need to register a service in different registries why
> not create a new data source and point to the other registry from
> there? The need to be able to select a registry is crucial for us,
> but once it is selected I don't think it should change.
>
> Now for the tests, I wanted to deregister the current services
> before changing registry, but it doesn't allow me to do so, it says
> that:
>
> BioMOBY Settings
>
> The service <b>getTaxaOfBoundingBox</b> could not be deregistered.
> Is the central MOBY registry accesible?
>
> 1) Services you are already publishing and registry where you
> registered them:
>
> TestServiceABCD ()Deregister
> getTaxaOfBoundingBox ()Deregister
> Deregister all
> 2) Considering the mappings that you already have done, you could
> be publishing:
>
> There are no other services available to register
> General settings
> BioMOBY registry end point
>
> BioMOBY registry Namespace
>
> bmttsUrl
>
> ServiceNs
>
> AuthURI
>
> ContactEmail
>
> databaseName
>
>
> Save
>
>
> It looks as if it cannot communicate with the registry end point (I
> left the Canada one).
>
> During the startup process of TAPIR I got a strange message:
>
> ERROR! from pywrapper: REQ_READ_MODEL_FAILED:::The requested model
> TCS 1.01 could not be read. Reason: Could not access external model
> component(s)
> Traceback (most recent call last):
> File "/Library/WebServer/Services/pywrapper/lib/biocase/pywrapper/
> model.py", line 252, in __readFile__
> self.parser.parse( file(filename) )
> File "/Library/WebServer/Services/pywrapper/tools/python/lib/
> python2.4/site-packages/_xmlplus/sax/expatreader.py", line 109, in
> parse
> xmlreader.IncrementalParser.parse(self, source)
> File "/Library/WebServer/Services/pywrapper/tools/python/lib/
> python2.4/site-packages/_xmlplus/sax/xmlreader.py", line 123, in parse
> self.feed(buffer)
> File "/Library/WebServer/Services/pywrapper/tools/python/lib/
> python2.4/site-packages/_xmlplus/sax/expatreader.py", line 216, in
> feed
> self._parser.Parse(data, isFinal)
> File "/Library/WebServer/Services/pywrapper/tools/python/lib/
> python2.4/site-packages/_xmlplus/sax/expatreader.py", line 353, in
> start_element_ns
> AttributesNSImpl(newattrs, qnames))
> File "/Library/WebServer/Services/pywrapper/lib/biocase/tools/
> saxhandler_extended.py", line 100, in startElementNS
> self.startSimpleElement(ns, localname.lower(), attributes)
> File "/Library/WebServer/Services/pywrapper/lib/biocase/pywrapper/
> model_handler.py", line 69, in startSimpleElement
> parser.parse(attrs.get('location'))
> File "/Library/WebServer/Services/pywrapper/tools/python/lib/
> python2.4/site-packages/_xmlplus/sax/expatreader.py", line 103, in
> parse
> source = saxutils.prepare_input_source(source)
> File "/Library/WebServer/Services/pywrapper/tools/python/lib/
> python2.4/site-packages/_xmlplus/sax/saxutils.py", line 523, in
> prepare_input_source
> f = urllib2.urlopen(source.getSystemId())
> File "/Library/WebServer/Services/pywrapper/tools/python/lib/
> python2.4/urllib2.py", line 130, in urlopen
> return _opener.open(url, data)
> File "/Library/WebServer/Services/pywrapper/tools/python/lib/
> python2.4/urllib2.py", line 358, in open
> response = self._open(req, data)
> File "/Library/WebServer/Services/pywrapper/tools/python/lib/
> python2.4/urllib2.py", line 376, in _open
> '_open', req)
> File "/Library/WebServer/Services/pywrapper/tools/python/lib/
> python2.4/urllib2.py", line 337, in _call_chain
> result = func(*args)
> File "/Library/WebServer/Services/pywrapper/tools/python/lib/
> python2.4/urllib2.py", line 1021, in http_open
> return self.do_open(httplib.HTTPConnection, req)
> File "/Library/WebServer/Services/pywrapper/tools/python/lib/
> python2.4/urllib2.py", line 996, in do_open
> raise URLError(err)
> URLError: <urlopen error (60, 'Operation timed out')>
> WARNING! from pywrapper: The model http://rs.tdwg.org/tapir/cs/
> tcs1.01/model/tcs101.xml could not be loaded. It might be corrupt.
>
> It looks like the TCS model is corrupt.
>
> Let me know if you need other information.
>
> Ciao!
>
> Milko
>
> On Nov 19, 2006, at 20:11 , Javier de la Torre wrote:
>
>> Hi Milko,
>>
>> Ok. I have implemented some sort of multiple biomoby registry
>> awareness in pywrapper.
>>
>> Now in the MOBY tab there are two new fields in the General Settings:
>>
>> "BioMOBY registry end point" and "BioMOBY registry Namespace".
>>
>> This let you choose the registry you want to use. This information
>> is saved as a general setting for this datasource. But preparing
>> the work for the future now when you register a service the
>> information of the end point and the namespace is stored in the
>> service on the config files, thats allowing the same service to be
>> register in multiple biomoby registries.
>>
>> When you click on register a service the configtool uses the
>> registry specify at this moment on the general settings, but when
>> you click on Deregister it uses the registry that was used for
>> registration.
>>
>> By default I have left configured the CENTRAL MOBY REGISTRY in
>> Canada. Milko, if you think more people are going to use the IRRI
>> one I can change it, give me the end point and ns and I change it
>> on the default config file so that new installations will appear
>> with this.
>>
>> There are some limitations still that I hope will not prevent us
>> from delopying right now:
>>
>> -Althought the config tool stores the info on the registry that
>> was used for registering a service, the interface will still not
>> offer you the possibility to register the same service in multiple
>> registries. If the config tool detects that a certain service has
>> been already registered in a registry is not offered as a
>> potential service. In the config files is still possible to
>> configure the same service in multiple registries, altought you
>> would have to manually register them using Dashboard or something
>> like this...
>>
>> -The BMTTS file gives pywrapper a list of service templates, but
>> it does not tell you for what registry this templates are
>> designed. Different registries have different data types. So a
>> service template for the IRRI server does not necessarily have to
>> work with the Central one in Canada... Therefore is needed that
>> the BMTTS stores information about to which registry a certain
>> template was designed. Then the config tool should read this info
>> and react according to this...
>>
>> I have only tried it with the central moby registry in Canada, but
>> I suppose it should work with others. I havent tried because I
>> dont have the url of the IRRI registry and the
>> getCoordinatesOfTaxon service template will probably not work with
>> the data types there... Could you try Milko with yours?
>>
>>
>> It is commited now.
>>
>> Javi.
>
|
|
From: Skofic A. M. (IPGRI) <m.s...@cg...> - 2006-11-20 09:35:25
|
I am trying now with the changes. I had to update the moby
configuration files to get into the user interface.
First of all, I think that having one registry per data source is
fine, if you need to register a service in different registries why
not create a new data source and point to the other registry from
there? The need to be able to select a registry is crucial for us,
but once it is selected I don't think it should change.
Now for the tests, I wanted to deregister the current services before
changing registry, but it doesn't allow me to do so, it says that:
BioMOBY Settings
The service <b>getTaxaOfBoundingBox</b> could not be deregistered. Is
the central MOBY registry accesible?
1) Services you are already publishing and registry where you
registered them:
TestServiceABCD ()Deregister
getTaxaOfBoundingBox ()Deregister
Deregister all
2) Considering the mappings that you already have done, you could be
publishing:
There are no other services available to register
General settings
BioMOBY registry end point
BioMOBY registry Namespace
bmttsUrl
ServiceNs
AuthURI
ContactEmail
databaseName
Save
It looks as if it cannot communicate with the registry end point (I
left the Canada one).
During the startup process of TAPIR I got a strange message:
ERROR! from pywrapper: REQ_READ_MODEL_FAILED:::The requested model
TCS 1.01 could not be read. Reason: Could not access external model
component(s)
Traceback (most recent call last):
File "/Library/WebServer/Services/pywrapper/lib/biocase/pywrapper/
model.py", line 252, in __readFile__
self.parser.parse( file(filename) )
File "/Library/WebServer/Services/pywrapper/tools/python/lib/
python2.4/site-packages/_xmlplus/sax/expatreader.py", line 109, in parse
xmlreader.IncrementalParser.parse(self, source)
File "/Library/WebServer/Services/pywrapper/tools/python/lib/
python2.4/site-packages/_xmlplus/sax/xmlreader.py", line 123, in parse
self.feed(buffer)
File "/Library/WebServer/Services/pywrapper/tools/python/lib/
python2.4/site-packages/_xmlplus/sax/expatreader.py", line 216, in feed
self._parser.Parse(data, isFinal)
File "/Library/WebServer/Services/pywrapper/tools/python/lib/
python2.4/site-packages/_xmlplus/sax/expatreader.py", line 353, in
start_element_ns
AttributesNSImpl(newattrs, qnames))
File "/Library/WebServer/Services/pywrapper/lib/biocase/tools/
saxhandler_extended.py", line 100, in startElementNS
self.startSimpleElement(ns, localname.lower(), attributes)
File "/Library/WebServer/Services/pywrapper/lib/biocase/pywrapper/
model_handler.py", line 69, in startSimpleElement
parser.parse(attrs.get('location'))
File "/Library/WebServer/Services/pywrapper/tools/python/lib/
python2.4/site-packages/_xmlplus/sax/expatreader.py", line 103, in parse
source = saxutils.prepare_input_source(source)
File "/Library/WebServer/Services/pywrapper/tools/python/lib/
python2.4/site-packages/_xmlplus/sax/saxutils.py", line 523, in
prepare_input_source
f = urllib2.urlopen(source.getSystemId())
File "/Library/WebServer/Services/pywrapper/tools/python/lib/
python2.4/urllib2.py", line 130, in urlopen
return _opener.open(url, data)
File "/Library/WebServer/Services/pywrapper/tools/python/lib/
python2.4/urllib2.py", line 358, in open
response = self._open(req, data)
File "/Library/WebServer/Services/pywrapper/tools/python/lib/
python2.4/urllib2.py", line 376, in _open
'_open', req)
File "/Library/WebServer/Services/pywrapper/tools/python/lib/
python2.4/urllib2.py", line 337, in _call_chain
result = func(*args)
File "/Library/WebServer/Services/pywrapper/tools/python/lib/
python2.4/urllib2.py", line 1021, in http_open
return self.do_open(httplib.HTTPConnection, req)
File "/Library/WebServer/Services/pywrapper/tools/python/lib/
python2.4/urllib2.py", line 996, in do_open
raise URLError(err)
URLError: <urlopen error (60, 'Operation timed out')>
WARNING! from pywrapper: The model http://rs.tdwg.org/tapir/cs/
tcs1.01/model/tcs101.xml could not be loaded. It might be corrupt.
It looks like the TCS model is corrupt.
Let me know if you need other information.
Ciao!
Milko
On Nov 19, 2006, at 20:11 , Javier de la Torre wrote:
> Hi Milko,
>
> Ok. I have implemented some sort of multiple biomoby registry
> awareness in pywrapper.
>
> Now in the MOBY tab there are two new fields in the General Settings:
>
> "BioMOBY registry end point" and "BioMOBY registry Namespace".
>
> This let you choose the registry you want to use. This information
> is saved as a general setting for this datasource. But preparing
> the work for the future now when you register a service the
> information of the end point and the namespace is stored in the
> service on the config files, thats allowing the same service to be
> register in multiple biomoby registries.
>
> When you click on register a service the configtool uses the
> registry specify at this moment on the general settings, but when
> you click on Deregister it uses the registry that was used for
> registration.
>
> By default I have left configured the CENTRAL MOBY REGISTRY in
> Canada. Milko, if you think more people are going to use the IRRI
> one I can change it, give me the end point and ns and I change it
> on the default config file so that new installations will appear
> with this.
>
> There are some limitations still that I hope will not prevent us
> from delopying right now:
>
> -Althought the config tool stores the info on the registry that was
> used for registering a service, the interface will still not offer
> you the possibility to register the same service in multiple
> registries. If the config tool detects that a certain service has
> been already registered in a registry is not offered as a potential
> service. In the config files is still possible to configure the
> same service in multiple registries, altought you would have to
> manually register them using Dashboard or something like this...
>
> -The BMTTS file gives pywrapper a list of service templates, but it
> does not tell you for what registry this templates are designed.
> Different registries have different data types. So a service
> template for the IRRI server does not necessarily have to work with
> the Central one in Canada... Therefore is needed that the BMTTS
> stores information about to which registry a certain template was
> designed. Then the config tool should read this info and react
> according to this...
>
> I have only tried it with the central moby registry in Canada, but
> I suppose it should work with others. I havent tried because I dont
> have the url of the IRRI registry and the getCoordinatesOfTaxon
> service template will probably not work with the data types
> there... Could you try Milko with yours?
>
>
> It is commited now.
>
> Javi.
|
|
From: Javier de la T. <ja...@gm...> - 2006-11-20 00:37:33
|
Hi all, I have edited the mailing list page on the wiki and now it is only pointing only to this mailing list. I have sent invitations to all people (5) that were on the users mailing list and not in the devel with an explanation and I hope they will decide to move here. I havent really close the users mailing list just in case people have still links or presentations with the url on them. I think I will close it in the enxt months. Javier. |
|
From: Javier de la T. <ja...@gm...> - 2006-11-20 00:15:53
|
Hi Milko, I think we can start discussing on the mailing list and then add tickets when we consider. Javi. On 19/11/2006, at 22:55, Skofic A. Milko (IPGRI) wrote: > No problem, I have no problem in sharing views, do you prefer an e- > mail discussion or a series of tickets? > > On Nov 19, 2006, at 20:23 , Javier de la Torre wrote: > >> Hi Milko, >> >>> Once we have released TAPIR can we have a skype or talk to see >>> what we can do in the future? What are the plans for the future, >>> Could we make a wish list and plan how we can implement it? >>> >> >> I prefer if you express your wishes here on the public list so >> that people knows what is going on. Maybe your wishes are the same >> as others and there is someone already planning it. >> >> After expressing the wishes here on the list then we can add the >> to the trac where there is already 10 or more wishes of things we >> would like to see in pywrapper. >> >> Cheers. >> >> JAvi. >> >>> Bye! >>> >>> Milko >>> >>> On Nov 17, 2006, at 13:53 , Javier de la Torre wrote: >>> >>>> Hi Milko, >>>> >>>> I have to watch out the refresh issue in moby. Adding the >>>> possibility to choose a moby central should not be complicate >>>> with an important consideration. Should we allow users to have >>>> services registered in different MOBY registries? If so, the >>>> configuration files must be changed to use as a service >>>> identifier the serviceName, authURI and THE REGISTRY were it was >>>> registered. This is important to know from where to register and >>>> deregister the services. >>>> >>>> If a pywrapper installation can work only with one single MOBY >>>> registry then it is easier, I can just add an input field in the >>>> configtool to allow users to write the endpoint of the registry >>>> they wanna use. >>>> >>>> I believe that the correct solution is to be "multiple >>>> registries aware" in pywrapper, but this will take a little bit >>>> more of time, meanwhile this weekend I can add you the simple >>>> solution... >>>> >>>> Cheers. >>>> >>>> >>>> On 17/11/2006, at 13:44, Skofic A. Milko (IPGRI) wrote: >>>> >>>>> Javier, I finally made my first MOBy service, >>>>> getTaxaOfBoundingBox, if you are interested in adding it to the >>>>> examples I send you the files, remember to change the links in >>>>> the files, they point to the eurisco site. >>>>> >>>>> There is a problem when you register a new MOBY service: TAPIR >>>>> takes a while before recognising that the service is up and >>>>> running; when testing one must manually delete the cache files >>>>> to test it with Dashboard. >>>>> >>>>> Do you think we can get a way to set the MOBY central? >>>>> >>>>> Ciao! >>>>> >>>>> Milko >>>>> >>>>> <getTaxaOfBoundingBox.bmtts.xml> >>>>> This is the BMTTS section. >>>>> >>>>> <getTaxaOfBoundingBox.bmtts.xml> >>>>> This is the output model. >>>>> >>>>> <BoundingBox.xslt> >>>>> This is the input transformation stylesheet. >>>>> >>>>> <TaxonScientificName.xsd> >>>>> This is the schema for the MOBY taxon name. >>>>> >>>>> >>>> >>> >>> >>> Milko A. Skofic (IPGRI) >>> International Plant Genetic Resources Institute >>> Via dei Tre Denari, 472/a >>> 00057 Maccarese (RM) >>> ITALY >>> E-mail: m.s...@cg... >>> Tel: +30 06 6118286 >>> >>> >> > > > Milko A. Skofic (IPGRI) > International Plant Genetic Resources Institute > Via dei Tre Denari, 472/a > 00057 Maccarese (RM) > ITALY > E-mail: m.s...@cg... > Tel: +30 06 6118286 > > |
|
From: Skofic A. M. (IPGRI) <m.s...@cg...> - 2006-11-19 21:55:51
|
No problem, I have no problem in sharing views, do you prefer an e- mail discussion or a series of tickets? On Nov 19, 2006, at 20:23 , Javier de la Torre wrote: > Hi Milko, > >> Once we have released TAPIR can we have a skype or talk to see >> what we can do in the future? What are the plans for the future, >> Could we make a wish list and plan how we can implement it? >> > > I prefer if you express your wishes here on the public list so that > people knows what is going on. Maybe your wishes are the same as > others and there is someone already planning it. > > After expressing the wishes here on the list then we can add the to > the trac where there is already 10 or more wishes of things we > would like to see in pywrapper. > > Cheers. > > JAvi. > >> Bye! >> >> Milko >> >> On Nov 17, 2006, at 13:53 , Javier de la Torre wrote: >> >>> Hi Milko, >>> >>> I have to watch out the refresh issue in moby. Adding the >>> possibility to choose a moby central should not be complicate >>> with an important consideration. Should we allow users to have >>> services registered in different MOBY registries? If so, the >>> configuration files must be changed to use as a service >>> identifier the serviceName, authURI and THE REGISTRY were it was >>> registered. This is important to know from where to register and >>> deregister the services. >>> >>> If a pywrapper installation can work only with one single MOBY >>> registry then it is easier, I can just add an input field in the >>> configtool to allow users to write the endpoint of the registry >>> they wanna use. >>> >>> I believe that the correct solution is to be "multiple registries >>> aware" in pywrapper, but this will take a little bit more of >>> time, meanwhile this weekend I can add you the simple solution... >>> >>> Cheers. >>> >>> >>> On 17/11/2006, at 13:44, Skofic A. Milko (IPGRI) wrote: >>> >>>> Javier, I finally made my first MOBy service, >>>> getTaxaOfBoundingBox, if you are interested in adding it to the >>>> examples I send you the files, remember to change the links in >>>> the files, they point to the eurisco site. >>>> >>>> There is a problem when you register a new MOBY service: TAPIR >>>> takes a while before recognising that the service is up and >>>> running; when testing one must manually delete the cache files >>>> to test it with Dashboard. >>>> >>>> Do you think we can get a way to set the MOBY central? >>>> >>>> Ciao! >>>> >>>> Milko >>>> >>>> <getTaxaOfBoundingBox.bmtts.xml> >>>> This is the BMTTS section. >>>> >>>> <getTaxaOfBoundingBox.bmtts.xml> >>>> This is the output model. >>>> >>>> <BoundingBox.xslt> >>>> This is the input transformation stylesheet. >>>> >>>> <TaxonScientificName.xsd> >>>> This is the schema for the MOBY taxon name. >>>> >>>> >>> >> >> >> Milko A. Skofic (IPGRI) >> International Plant Genetic Resources Institute >> Via dei Tre Denari, 472/a >> 00057 Maccarese (RM) >> ITALY >> E-mail: m.s...@cg... >> Tel: +30 06 6118286 >> >> > Milko A. Skofic (IPGRI) International Plant Genetic Resources Institute Via dei Tre Denari, 472/a 00057 Maccarese (RM) ITALY E-mail: m.s...@cg... Tel: +30 06 6118286 |
|
From: Skofic A. M. (IPGRI) <m.s...@cg...> - 2006-11-19 21:54:34
|
I will try it tomorrow, I also didn't know the address of the IRRI registry, but Martin told me to update Dashboard and in the new version you have a popup list with all the registries. Will let you know. Chao! Milko On Nov 19, 2006, at 20:11 , Javier de la Torre wrote: > Hi Milko, > > Ok. I have implemented some sort of multiple biomoby registry > awareness in pywrapper. > > Now in the MOBY tab there are two new fields in the General Settings: > > "BioMOBY registry end point" and "BioMOBY registry Namespace". > > This let you choose the registry you want to use. This information > is saved as a general setting for this datasource. But preparing > the work for the future now when you register a service the > information of the end point and the namespace is stored in the > service on the config files, thats allowing the same service to be > register in multiple biomoby registries. > > When you click on register a service the configtool uses the > registry specify at this moment on the general settings, but when > you click on Deregister it uses the registry that was used for > registration. > > By default I have left configured the CENTRAL MOBY REGISTRY in > Canada. Milko, if you think more people are going to use the IRRI > one I can change it, give me the end point and ns and I change it > on the default config file so that new installations will appear > with this. > > There are some limitations still that I hope will not prevent us > from delopying right now: > > -Althought the config tool stores the info on the registry that was > used for registering a service, the interface will still not offer > you the possibility to register the same service in multiple > registries. If the config tool detects that a certain service has > been already registered in a registry is not offered as a potential > service. In the config files is still possible to configure the > same service in multiple registries, altought you would have to > manually register them using Dashboard or something like this... > > -The BMTTS file gives pywrapper a list of service templates, but it > does not tell you for what registry this templates are designed. > Different registries have different data types. So a service > template for the IRRI server does not necessarily have to work with > the Central one in Canada... Therefore is needed that the BMTTS > stores information about to which registry a certain template was > designed. Then the config tool should read this info and react > according to this... > > I have only tried it with the central moby registry in Canada, but > I suppose it should work with others. I havent tried because I dont > have the url of the IRRI registry and the getCoordinatesOfTaxon > service template will probably not work with the data types > there... Could you try Milko with yours? > > > It is commited now. > > Javi. Milko A. Skofic (IPGRI) International Plant Genetic Resources Institute Via dei Tre Denari, 472/a 00057 Maccarese (RM) ITALY E-mail: m.s...@cg... Tel: +30 06 6118286 |
|
From: Javier de la T. <ja...@gm...> - 2006-11-19 20:12:05
|
Hi all, During last TDWG I talked with Markus and other people about PyWrappers logo. The TAPIR we have right now we dont like it because it brings confussion about what is TAPIR, the protocol, and what is PyWrapper, just one implementation of the TAPIR protocol + other protocols. I forgot in my presentation at TDWG about PyWrapper to talk about the logo thing... but we thought that it could be a good idea to have a logo contest! Sally already gave us some ideas of pythons wrapping TAPIRs and things like that. I have prepared a page on the wiki to start writing a little document about it. http://trac.pywrapper.org/pywrapper/wiki/LogoContest Markus and I are very busy those days so it would be great if someone can volunteer to organize the contest. It is mainly about writing a document with the rules, look for a prize or whatever (recognition?), promote it in mailing lists or in the web, recieve the proposals from the participants, set up a page with them for people to evaluate and finally collect the votes form the community and declare a winner. Is there anybody that wants to organize this? Thanks in advance. Javier. |
|
From: Javier de la T. <ja...@gm...> - 2006-11-19 19:47:59
|
> Hi Milko,. > This is what I want to try. To begin, I have a question on the > BasisOfRecord element of the OccurrenceRecord data type: what does > it mean? I assume you might know about this because the data type > was created by GBIF. Look at the ABCD documentation: http://ww3.bgbm.org/abcddocs/AbcdConcept0400 > I am also starting to struggle with XSLT and... you can imagine... > With simple XML structures it is easy to work, but with the MOBy > stuff it's hard. Actually with BioMOBY is pretty simple because the XSLT you have to produce just hve to take care of getting a value from and element using and Xpath. So we are actually using XSLT mainly only to use Xpath... And be careful when constructing the xpaths! Follow the example in my getCoordinatesOfTaxon. As you know in BioMOBY a service must be prepared to recieved requests using data types that he might dont know. You just have to believe that the user is doing right and you take the data and process it. For this the xpath must be generic enough so that changes on the structure still work with it... if not you will not create compliant biomoby services. I did not know, but using xpath in biomoby services to retrieve "agnostically" the contents of the requests is something normal, I asked in their mailing lists, so if you have troubles you could actually ask in this mailing lists for a suitable xpath for the new service you want to create. Javi. |
|
From: Javier de la T. <ja...@gm...> - 2006-11-19 19:36:12
|
Hi Peter, > I've installed from an anonymous checkout using both the standard > install script and to the system using apt etc - both seem to work > fine. Unfortunately the instructions for using FastCGI do not work on > my system - I think this is because Kubuntu packages Apache in an > awkward way. I'll look at providing documentation at some point > but for > now I'll just use as a standalone server. Out of interest what is the > distro of choice in the PyWrapper community? > I suppose dont really have one... but we should do a wiki page with a list of platforms where we have tested the software and issues with it. I have tried with: -Mac os X 10.4 -Red Hat 9 -Windows XP Pro -Ubuntu But always using the cherrypy stand alone server, we need much more testing and documentation on setting up the fastcgi way and the redirection... And we need to start writing this on the wiki! > The next problem I have is that there is a considerable delay between > running start_server.py and the server actually coming online (I've > timed it to 3mins 10secs). Whilst in itself this isn't such a big > deal > (after all I'll only be (re)starting the server very occasionally once > I've got everything live!) but I'm worried this is indicative of a > problem. Can anyone give me their experiences on startup times? Markus, already answer this... In my case it takes around 20 seconds when downloading and parsing things... I wonder why it takes so much time for you... Javi. |
|
From: Javier de la T. <ja...@gm...> - 2006-11-19 19:24:05
|
Hi Milko, > Once we have released TAPIR can we have a skype or talk to see what > we can do in the future? What are the plans for the future, Could > we make a wish list and plan how we can implement it? > I prefer if you express your wishes here on the public list so that people knows what is going on. Maybe your wishes are the same as others and there is someone already planning it. After expressing the wishes here on the list then we can add the to the trac where there is already 10 or more wishes of things we would like to see in pywrapper. Cheers. JAvi. > Bye! > > Milko > > On Nov 17, 2006, at 13:53 , Javier de la Torre wrote: > >> Hi Milko, >> >> I have to watch out the refresh issue in moby. Adding the >> possibility to choose a moby central should not be complicate with >> an important consideration. Should we allow users to have services >> registered in different MOBY registries? If so, the configuration >> files must be changed to use as a service identifier the >> serviceName, authURI and THE REGISTRY were it was registered. This >> is important to know from where to register and deregister the >> services. >> >> If a pywrapper installation can work only with one single MOBY >> registry then it is easier, I can just add an input field in the >> configtool to allow users to write the endpoint of the registry >> they wanna use. >> >> I believe that the correct solution is to be "multiple registries >> aware" in pywrapper, but this will take a little bit more of time, >> meanwhile this weekend I can add you the simple solution... >> >> Cheers. >> >> >> On 17/11/2006, at 13:44, Skofic A. Milko (IPGRI) wrote: >> >>> Javier, I finally made my first MOBy service, >>> getTaxaOfBoundingBox, if you are interested in adding it to the >>> examples I send you the files, remember to change the links in >>> the files, they point to the eurisco site. >>> >>> There is a problem when you register a new MOBY service: TAPIR >>> takes a while before recognising that the service is up and >>> running; when testing one must manually delete the cache files to >>> test it with Dashboard. >>> >>> Do you think we can get a way to set the MOBY central? >>> >>> Ciao! >>> >>> Milko >>> >>> <getTaxaOfBoundingBox.bmtts.xml> >>> This is the BMTTS section. >>> >>> <getTaxaOfBoundingBox.bmtts.xml> >>> This is the output model. >>> >>> <BoundingBox.xslt> >>> This is the input transformation stylesheet. >>> >>> <TaxonScientificName.xsd> >>> This is the schema for the MOBY taxon name. >>> >>> >> > > > Milko A. Skofic (IPGRI) > International Plant Genetic Resources Institute > Via dei Tre Denari, 472/a > 00057 Maccarese (RM) > ITALY > E-mail: m.s...@cg... > Tel: +30 06 6118286 > > |
|
From: Javier de la T. <ja...@gm...> - 2006-11-19 19:12:15
|
Hi Milko, Ok. I have implemented some sort of multiple biomoby registry awareness in pywrapper. Now in the MOBY tab there are two new fields in the General Settings: "BioMOBY registry end point" and "BioMOBY registry Namespace". This let you choose the registry you want to use. This information is saved as a general setting for this datasource. But preparing the work for the future now when you register a service the information of the end point and the namespace is stored in the service on the config files, thats allowing the same service to be register in multiple biomoby registries. When you click on register a service the configtool uses the registry specify at this moment on the general settings, but when you click on Deregister it uses the registry that was used for registration. By default I have left configured the CENTRAL MOBY REGISTRY in Canada. Milko, if you think more people are going to use the IRRI one I can change it, give me the end point and ns and I change it on the default config file so that new installations will appear with this. There are some limitations still that I hope will not prevent us from delopying right now: -Althought the config tool stores the info on the registry that was used for registering a service, the interface will still not offer you the possibility to register the same service in multiple registries. If the config tool detects that a certain service has been already registered in a registry is not offered as a potential service. In the config files is still possible to configure the same service in multiple registries, altought you would have to manually register them using Dashboard or something like this... -The BMTTS file gives pywrapper a list of service templates, but it does not tell you for what registry this templates are designed. Different registries have different data types. So a service template for the IRRI server does not necessarily have to work with the Central one in Canada... Therefore is needed that the BMTTS stores information about to which registry a certain template was designed. Then the config tool should read this info and react according to this... I have only tried it with the central moby registry in Canada, but I suppose it should work with others. I havent tried because I dont have the url of the IRRI registry and the getCoordinatesOfTaxon service template will probably not work with the data types there... Could you try Milko with yours? It is commited now. Javi. |
|
From: Skofic A. M. (IPGRI) <m.s...@cg...> - 2006-11-19 12:24:55
|
I realise it could become a mess, since you wouldn't know where you have registered your services. For the moment let's go for the simple solution: a field where you set the registry and that's all. Once we have released TAPIR can we have a skype or talk to see what we can do in the future? What are the plans for the future, Could we make a wish list and plan how we can implement it? Bye! Milko On Nov 17, 2006, at 13:53 , Javier de la Torre wrote: > Hi Milko, > > I have to watch out the refresh issue in moby. Adding the > possibility to choose a moby central should not be complicate with > an important consideration. Should we allow users to have services > registered in different MOBY registries? If so, the configuration > files must be changed to use as a service identifier the > serviceName, authURI and THE REGISTRY were it was registered. This > is important to know from where to register and deregister the > services. > > If a pywrapper installation can work only with one single MOBY > registry then it is easier, I can just add an input field in the > configtool to allow users to write the endpoint of the registry > they wanna use. > > I believe that the correct solution is to be "multiple registries > aware" in pywrapper, but this will take a little bit more of time, > meanwhile this weekend I can add you the simple solution... > > Cheers. > > > On 17/11/2006, at 13:44, Skofic A. Milko (IPGRI) wrote: > >> Javier, I finally made my first MOBy service, >> getTaxaOfBoundingBox, if you are interested in adding it to the >> examples I send you the files, remember to change the links in the >> files, they point to the eurisco site. >> >> There is a problem when you register a new MOBY service: TAPIR >> takes a while before recognising that the service is up and >> running; when testing one must manually delete the cache files to >> test it with Dashboard. >> >> Do you think we can get a way to set the MOBY central? >> >> Ciao! >> >> Milko >> >> <getTaxaOfBoundingBox.bmtts.xml> >> This is the BMTTS section. >> >> <getTaxaOfBoundingBox.bmtts.xml> >> This is the output model. >> >> <BoundingBox.xslt> >> This is the input transformation stylesheet. >> >> <TaxonScientificName.xsd> >> This is the schema for the MOBY taxon name. >> >> > Milko A. Skofic (IPGRI) International Plant Genetic Resources Institute Via dei Tre Denari, 472/a 00057 Maccarese (RM) ITALY E-mail: m.s...@cg... Tel: +30 06 6118286 |
|
From: <m.d...@BG...> - 2006-11-17 13:20:50
|
great! -----Original Message----- From: pyw...@li... = [mailto:pyw...@li...] On Behalf Of = Javier privat Sent: Freitag, 17. November 2006 13:56 To: "Markus D=F6ring"=20 Cc: PyWrapper Developers mailing list Subject: Re: [PyWrapper-devel] A problem... =09 =09 Hi Markus,=20 This weekend I will add the possibility to choose the moby registry and = with this I think we are done! Monday release! Javi. On 17/11/2006, at 13:51, Markus D=F6ring wrote: so I am gone over the weekend. if there are no more bugs detected by monday we do our first release? what do you think? javi, anythin from your side left to do? some code = cosmetics? markus =09 =09 =09 On 11/17/06, Skofic A. Milko (IPGRI) <M.S...@cg...> wrote:=20 Oh sh... I am buggy! Sorry. Will check the MOBy files, probably there is an incorrect = concept ID. Ciao! =09 ink =09 Milko =09 =09 On Nov 17, 2006, at 13:36 , Markus D=F6ring wrote: Milko, thats because you got the ABCD coordinate concepts wrong. Theres a double DataSets/DataSets/ part in it. the wrapper doesnt = know it and evaluates the comparison (isNull) to False. butthe Not makes = it True again!=20 =09 still no buggy code! markus =09 =09 =09 On 11/17/06, Skofic A. Milko (IPGRI) < M.S...@cg... = <mailto:M.S...@cg...> > wrote:=20 Put down those champagne glasses... :-) just joking, however there = is a problem with the not null stuff. I am sending this query:=20 <?xml version=3D'1.0' encoding=3D'UTF-8'?> <request>=20 <header> <source = accesspoint=3D"http://tapir.grinfo.net:8080/pywrapper/pywrapper?dsa=3DEUR= ISCO " sendtime=3D"2006-11-16T23:44:59.14"/> </header> <search count=3D'true' start=3D'0' limit=3D'50'> <externalOutputModel = location=3D"http://eurisco.ecpgr.org/models/moby/TestService.xml "/> <filter> <and> <like> <concept id=3D" = http://www.tdwg.org/schemas/abcd/2.06/DataSets/DataSet/Units/Unit/Identif= ications/Identification/Result/TaxonIdentified/ScientificName/FullScienti= ficNameString = <http://www.tdwg.org/schemas/abcd/2.06/DataSets/DataSet/Units/Unit/Identi= fications/Identification/Result/TaxonIdentified/ScientificName/FullScient= ificNameString> "> </concept> <literal value=3D"b*" />=20 </like> <not> <isNull> <concept id=3D" = http://www.tdwg.org/schemas/abcd/2.06/DataSets/DataSets/DataSet/Units/Uni= t/Gathering/SiteCoordinateSets/SiteCoordinates/CoordinatesLatLong/Latitud= eDecimal = <http://www.tdwg.org/schemas/abcd/2.06/DataSets/DataSets/DataSet/Units/Un= it/Gathering/SiteCoordinateSets/SiteCoordinates/CoordinatesLatLong/Latitu= deDecimal> "> </concept> </isNull>=20 </not> <not> <isNull>=20 <concept id=3D" = http://www.tdwg.org/schemas/abcd/2.06/DataSets/DataSets/DataSet/Units/Uni= t/Gathering/SiteCoordinateSets/SiteCoordinates/CoordinatesLatLong/Longitu= deDecimal = <http://www.tdwg.org/schemas/abcd/2.06/DataSets/DataSets/DataSet/Units/Un= it/Gathering/SiteCoordinateSets/SiteCoordinates/CoordinatesLatLong/Longit= udeDecimal> "> </concept> </isNull>=20 </not> </and> </filter> </search> </request> This query is the query that TAPIR would use to get the data for = the getCoordinatesOfTaxon MOBY service.=20 When I try it with the training and EURISCO_TEST data sources it = works, when I send it to the EURISCO data source it returns a bunch of = records without latitude and longitude. When you look at the SQLs it produces you see nowhere in the WHERE = clauses the test for the NULL latitudes and longitudes. =20 If you want to test the corresponding MOBY services, for = datasources: EURISCO -> eurisco.ecpgr.org -> TestServiceABCD EURISCO_TEST -> test.eurisco.ecpgr.org -> TestServiceABCD training -> test.ipgri.ecpgr.org -> getCoordinatesOfTaxon I am sending you the whole package of the MOBY service files in = case you need to check things, anyways you know the passwords of = http://tapir.grinfo.net:8080/pywrapper/ =09 =09 =09 =09 =09 =09 =09 =09 I will get back to you during the week end, this afternoon I am not = here. Bye! Milko |
|
From: Javier de la T. <ja...@gm...> - 2006-11-17 12:56:38
|
Hi Markus, This weekend I will add the possibility to choose the moby registry =20 and with this I think we are done! Monday release! Javi. On 17/11/2006, at 13:51, Markus D=F6ring wrote: > so I am gone over the weekend. > if there are no more bugs detected by monday we do our first release? > what do you think? javi, anythin from your side left to do? some =20 > code cosmetics? > markus > > > On 11/17/06, Skofic A. Milko (IPGRI) <M.S...@cg...> wrote: > Oh sh... I am buggy! > Sorry. Will check the MOBy files, probably there is an incorrect =20 > concept ID. > > Ciao! > ink > Milko > > On Nov 17, 2006, at 13:36 , Markus D=F6ring wrote: > >> Milko, >> thats because you got the ABCD coordinate concepts wrong. >> Theres a double DataSets/DataSets/ part in it. the wrapper doesnt =20 >> know it and evaluates the comparison (isNull) to False. butthe Not =20= >> makes it True again! >> >> still no buggy code! >> markus >> >> >> On 11/17/06, Skofic A. Milko (IPGRI) < M.S...@cg...> wrote: >> Put down those champagne glasses... :-) just joking, however there =20= >> is a problem with the not null stuff. I am sending this query: >> >> <?xml version=3D'1.0' encoding=3D'UTF-8'?> >> <request> >> <header> >> <source = accesspoint=3D"http://tapir.grinfo.net:8080/pywrapper/=20 >> pywrapper?dsa=3DEURISCO " sendtime=3D"2006-11-16T23:44:59.14"/> >> </header> >> <search count=3D'true' start=3D'0' limit=3D'50'> >> <externalOutputModel = location=3D"http://eurisco.ecpgr.org/models/=20 >> moby/TestService.xml "/> >> <filter> >> <and> >> <like> >> <concept id=3D" = http://www.tdwg.org/schemas/abcd/2.06/DataSets/=20 >> DataSet/Units/Unit/Identifications/Identification/Result/=20 >> TaxonIdentified/ScientificName/FullScientificNameString"> >> </concept> >> <literal value=3D"b*" /> >> </like> >> <not> >> <isNull> >> <concept id=3D" = http://www.tdwg.org/schemas/abcd/2.06/=20 >> DataSets/DataSets/DataSet/Units/Unit/Gathering/SiteCoordinateSets/=20 >> SiteCoordinates/CoordinatesLatLong/LatitudeDecimal"> >> </concept> >> </isNull> >> </not> >> <not> >> <isNull> >> <concept id=3D" = http://www.tdwg.org/schemas/abcd/2.06/=20 >> DataSets/DataSets/DataSet/Units/Unit/Gathering/SiteCoordinateSets/=20 >> SiteCoordinates/CoordinatesLatLong/LongitudeDecimal"> >> </concept> >> </isNull> >> </not> >> </and> >> </filter> >> </search> >> </request> >> >> This query is the query that TAPIR would use to get the data for =20 >> the getCoordinatesOfTaxon MOBY service. >> When I try it with the training and EURISCO_TEST data sources it =20 >> works, when I send it to the EURISCO data source it returns a =20 >> bunch of records without latitude and longitude. >> >> When you look at the SQLs it produces you see nowhere in the WHERE =20= >> clauses the test for the NULL latitudes and longitudes. >> >> If you want to test the corresponding MOBY services, for datasources: >> >> EURISCO -> eurisco.ecpgr.org -> = TestServiceABCD >> EURISCO_TEST -> test.eurisco.ecpgr.org -> TestServiceABCD >> training -> test.ipgri.ecpgr.org -> = getCoordinatesOfTaxon >> >> I am sending you the whole package of the MOBY service files in =20 >> case you need to check things, anyways you know the passwords of =20 >> http://tapir.grinfo.net:8080/pywrapper/ >> >> >> >> >> >> >> I will get back to you during the week end, this afternoon I am =20 >> not here. >> >> Bye! >> >> Milko >> >> >> > > |
|
From: Javier de la T. <ja...@gm...> - 2006-11-17 12:54:10
|
Hi Milko, I have to watch out the refresh issue in moby. Adding the possibility to choose a moby central should not be complicate with an important consideration. Should we allow users to have services registered in different MOBY registries? If so, the configuration files must be changed to use as a service identifier the serviceName, authURI and THE REGISTRY were it was registered. This is important to know from where to register and deregister the services. If a pywrapper installation can work only with one single MOBY registry then it is easier, I can just add an input field in the configtool to allow users to write the endpoint of the registry they wanna use. I believe that the correct solution is to be "multiple registries aware" in pywrapper, but this will take a little bit more of time, meanwhile this weekend I can add you the simple solution... Cheers. On 17/11/2006, at 13:44, Skofic A. Milko (IPGRI) wrote: > Javier, I finally made my first MOBy service, getTaxaOfBoundingBox, > if you are interested in adding it to the examples I send you the > files, remember to change the links in the files, they point to the > eurisco site. > > There is a problem when you register a new MOBY service: TAPIR > takes a while before recognising that the service is up and > running; when testing one must manually delete the cache files to > test it with Dashboard. > > Do you think we can get a way to set the MOBY central? > > Ciao! > > Milko > > <getTaxaOfBoundingBox.bmtts.xml> > This is the BMTTS section. > > <getTaxaOfBoundingBox.bmtts.xml> > This is the output model. > > <BoundingBox.xslt> > This is the input transformation stylesheet. > > <TaxonScientificName.xsd> > This is the schema for the MOBY taxon name. > > |
|
From: <m.d...@BG...> - 2006-11-17 11:15:19
|
Peter, there are no production installations of pywrapper2 yet. We intend to = recommend fastcgi when possible, but nearly all our development = installation use the standalone version cause its much easier to use. I = have only tested the fastcgi version on mac osx with apache1.3 so far = cause its pretty new. Before we were using mod_python which we installed = here at the bgbm under debian. That reminds me that I have to update = this installation... The delay when starting the server is mainly due to the fact that = pywrapper downloads and parses all models registered in the alias.txt = file, currently by default http://rs.tdwg.org/tapir/cns/alias.txt This takes quite some time and you should see some warning messages on = the console about not understood xml schema tags (its ok like this). The = startup time should be less for the subsequent times, cause pywrapper = caches downloaded files locally. Markus > -----Original Message----- > From: pyw...@li...=20 > [mailto:pyw...@li...] On=20 > Behalf Of Peter Brewer > Sent: Donnerstag, 16. November 2006 18:53 > To: pyw...@li... > Subject: [PyWrapper-devel] First impressions... >=20 >=20 > Dear All, >=20 > I'm just getting to grips with PyWrapper so please be gentle=20 > with me! =20 > I've installed PyWrapper on my Kubuntu Edgy desktop (AMD3200 2Gb RAM)=20 > and have a few observations and questions: >=20 > I've installed from an anonymous checkout using both the standard=20 > install script and to the system using apt etc - both seem to work=20 > fine. Unfortunately the instructions for using FastCGI do=20 > not work on=20 > my system - I think this is because Kubuntu packages Apache in an=20 > awkward way. I'll look at providing documentation at some=20 > point but for=20 > now I'll just use as a standalone server. Out of interest=20 > what is the=20 > distro of choice in the PyWrapper community? >=20 > The next problem I have is that there is a considerable delay between=20 > running start_server.py and the server actually coming online (I've=20 > timed it to 3mins 10secs). Whilst in itself this isn't such=20 > a big deal=20 > (after all I'll only be (re)starting the server very=20 > occasionally once=20 > I've got everything live!) but I'm worried this is indicative of a=20 > problem. Can anyone give me their experiences on startup times? >=20 > Once up and running the server seems very responsive most of the time=20 > but occasionally it can become very slow. I'm just working with the=20 > MySQL training database so it's just a standard installation.=20 > Using the=20 > Query Forms, it can happily return various requests but some times a=20 > search request (both DWC and ABCD) seems to stall the server. After=20 > this point the server stops responding for quite a long time=20 > until the=20 > connection times outs. Is this a CherryPy issue do you think=20 > or perhaps=20 > a problem with the version of MySQL / MySQLdb? Are most=20 > PyWrapper users=20 > running standalone servers or are they using FastCGI and Apache? >=20 > Many thanks >=20 > Peter >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the=20 > chance to share your opinions on IT & business topics through=20 > brief surveys - and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge &CID=3DDEVDEV _______________________________________________ PyWrapper-devel mailing list PyW...@li... https://lists.sourceforge.net/lists/listinfo/pywrapper-devel |
|
From: <m.d...@BG...> - 2006-11-17 10:26:39
|
+1 > -----Original Message----- > From: pyw...@li...=20 > [mailto:pyw...@li...] On=20 > Behalf Of Renato De Giovanni > Sent: Donnerstag, 16. November 2006 19:48 > To: PyWrapper Developers mailing list > Subject: Re: [PyWrapper-devel] Mailing lists >=20 >=20 > I think developers should always subscribe and participate in the=20 > users' mailing list. For me the main reason for keeping two separate=20 > lists is that users are not always interested in developers'=20 > discussions. But I really don't mind if you decide to unify=20 > them. So, Javi, in my case: 0 > -- > Renato >=20 > On 16 Nov 2006 at 19:10, Javier de la Torre wrote: >=20 > > Hey, > >=20 > > So we are going to use the typical mailing list system to vote for > > these kind of things... > >=20 > > If you read an email like mine you can reply just this: > >=20 > > +1 (you like the idea, vote for it, agree..) > > 0 (you dont mind, no clear position about it, does not=20 > affect you..)=20 > > -1 (you dont like it, you disagree, etc.) In this case you must give > > an explanation of why you vote against. > >=20 > > This can save everybodies time as the only think Peter could have > > written is "+1" and hit reply. > >=20 > > Do you like the idea? (Answer with the mechanism explained ;) > >=20 > > Cheers. > >=20 > > On 16/11/2006, at 19:03, Peter Brewer wrote: > >=20 > > > Javi, > > > > > > Yeah sorry... it was rather more a 'users' email than=20 > developers. =20 > > > To be > > > honest, I looked at the archives and saw that the users list was=20 > > > very quiet so thought it best to direct to the developers as you=20 > > > guys seem quite vocal! > > > > > > I'd go with your idea to merge the two as to be honest developers=20 > > > are quite often users for something like this. > > > > > > Cheers > > > > > > Pete > > > > > > > > > > > > Javier de la Torre wrote: > > >> Hi all, > > >> > > >> I am starting to wonder if it is necessary to keep separate the=20 > > >> user and developers mailing lists for pywrapper. Right=20 > now it looks=20 > > >> more like if we only use developers and this might give the=20 > > >> impression that nothing is going on with pywrapper for users...=20 > > >> This came to my mind while reading Peter last message. > > >> > > >> I would propose to merge the two mailing lists into one=20 > and if in=20 > > >> the future we really see the need to separate devel and=20 > users we go=20 > > >> for it... > > >> > > >> Does this make sense or is not really necessary to worry about=20 > > >> this? > > >> > > >> Javi. > > >> > > >>=20 > ------------------------------------------------------------------- > > >> -- > > >> ---- > > >> Take Surveys. Earn Cash. Influence the Future of IT > > >> Join SourceForge.net's Techsay panel and you'll get the=20 > chance to =20 > > >> share your > > >> opinions on IT & business topics through brief surveys -=20 > and earn =20 > > >> cash > > >> http://www.techsay.com/default.php?=20 > > >> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV > > >> _______________________________________________ > > >> PyWrapper-devel mailing list > > >> PyW...@li... > > >> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > > >> > > > > > > > > >=20 > -------------------------------------------------------------------- > > > -- > > > --- > > > Take Surveys. Earn Cash. Influence the Future of IT > > > Join SourceForge.net's Techsay panel and you'll get the=20 > chance to =20 > > > share your > > > opinions on IT & business topics through brief surveys -=20 > and earn cash > > > http://www.techsay.com/default.php?=20 > > > page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV > > > _______________________________________________ > > > PyWrapper-devel mailing list > > > PyW...@li... > > > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > --- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the=20 > chance to share your > > opinions on IT & business topics through brief surveys -=20 > and earn cash > >=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge &CID=3DDEVDEV > _______________________________________________ > PyWrapper-devel mailing list > PyW...@li... > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel -------------------------------------------------------------------------= Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share = your opinions on IT & business topics through brief surveys - and earn = cash = http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV _______________________________________________ PyWrapper-devel mailing list PyW...@li... https://lists.sourceforge.net/lists/listinfo/pywrapper-devel |
|
From: Renato De G. <re...@cr...> - 2006-11-16 18:51:31
|
I think developers should always subscribe and participate in the users' mailing list. For me the main reason for keeping two separate lists is that users are not always interested in developers' discussions. But I really don't mind if you decide to unify them. So, Javi, in my case: 0 -- Renato On 16 Nov 2006 at 19:10, Javier de la Torre wrote: > Hey, > > So we are going to use the typical mailing list system to vote for > these kind of things... > > If you read an email like mine you can reply just this: > > +1 (you like the idea, vote for it, agree..) > 0 (you dont mind, no clear position about it, does not affect you..) > -1 (you dont like it, you disagree, etc.) In this case you must give > an explanation of why you vote against. > > This can save everybodies time as the only think Peter could have > written is "+1" and hit reply. > > Do you like the idea? (Answer with the mechanism explained ;) > > Cheers. > > On 16/11/2006, at 19:03, Peter Brewer wrote: > > > Javi, > > > > Yeah sorry... it was rather more a 'users' email than developers. > > To be > > honest, I looked at the archives and saw that the users list was very > > quiet so thought it best to direct to the developers as you guys seem > > quite vocal! > > > > I'd go with your idea to merge the two as to be honest developers are > > quite often users for something like this. > > > > Cheers > > > > Pete > > > > > > > > Javier de la Torre wrote: > >> Hi all, > >> > >> I am starting to wonder if it is necessary to keep separate the user > >> and developers mailing lists for pywrapper. Right now it looks more > >> like if we only use developers and this might give the impression > >> that nothing is going on with pywrapper for users... This came to my > >> mind while reading Peter last message. > >> > >> I would propose to merge the two mailing lists into one and if in the > >> future we really see the need to separate devel and users we go for > >> it... > >> > >> Does this make sense or is not really necessary to worry about this? > >> > >> Javi. > >> > >> --------------------------------------------------------------------- > >> ---- > >> Take Surveys. Earn Cash. Influence the Future of IT > >> Join SourceForge.net's Techsay panel and you'll get the chance to > >> share your > >> opinions on IT & business topics through brief surveys - and earn > >> cash > >> http://www.techsay.com/default.php? > >> page=join.php&p=sourceforge&CID=DEVDEV > >> _______________________________________________ > >> PyWrapper-devel mailing list > >> PyW...@li... > >> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > >> > > > > > > ---------------------------------------------------------------------- > > --- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to > > share your > > opinions on IT & business topics through brief surveys - and earn cash > > http://www.techsay.com/default.php? > > page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > PyWrapper-devel mailing list > > PyW...@li... > > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > PyWrapper-devel mailing list > PyW...@li... > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel |
|
From: Javier de la T. <ja...@gm...> - 2006-11-16 18:11:54
|
Hey, So we are going to use the typical mailing list system to vote for these kind of things... If you read an email like mine you can reply just this: +1 (you like the idea, vote for it, agree..) 0 (you dont mind, no clear position about it, does not affect you..) -1 (you dont like it, you disagree, etc.) In this case you must give an explanation of why you vote against. This can save everybodies time as the only think Peter could have written is "+1" and hit reply. Do you like the idea? (Answer with the mechanism explained ;) Cheers. On 16/11/2006, at 19:03, Peter Brewer wrote: > Javi, > > Yeah sorry... it was rather more a 'users' email than developers. > To be > honest, I looked at the archives and saw that the users list was very > quiet so thought it best to direct to the developers as you guys seem > quite vocal! > > I'd go with your idea to merge the two as to be honest developers are > quite often users for something like this. > > Cheers > > Pete > > > > Javier de la Torre wrote: >> Hi all, >> >> I am starting to wonder if it is necessary to keep separate the user >> and developers mailing lists for pywrapper. Right now it looks more >> like if we only use developers and this might give the impression >> that nothing is going on with pywrapper for users... This came to my >> mind while reading Peter last message. >> >> I would propose to merge the two mailing lists into one and if in the >> future we really see the need to separate devel and users we go for >> it... >> >> Does this make sense or is not really necessary to worry about this? >> >> Javi. >> >> --------------------------------------------------------------------- >> ---- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to >> share your >> opinions on IT & business topics through brief surveys - and earn >> cash >> http://www.techsay.com/default.php? >> page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> PyWrapper-devel mailing list >> PyW...@li... >> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel >> > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > PyWrapper-devel mailing list > PyW...@li... > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel |
|
From: Peter B. <p.w...@re...> - 2006-11-16 18:02:41
|
Javi, Yeah sorry... it was rather more a 'users' email than developers. To be honest, I looked at the archives and saw that the users list was very quiet so thought it best to direct to the developers as you guys seem quite vocal! I'd go with your idea to merge the two as to be honest developers are quite often users for something like this. Cheers Pete Javier de la Torre wrote: > Hi all, > > I am starting to wonder if it is necessary to keep separate the user > and developers mailing lists for pywrapper. Right now it looks more > like if we only use developers and this might give the impression > that nothing is going on with pywrapper for users... This came to my > mind while reading Peter last message. > > I would propose to merge the two mailing lists into one and if in the > future we really see the need to separate devel and users we go for > it... > > Does this make sense or is not really necessary to worry about this? > > Javi. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > PyWrapper-devel mailing list > PyW...@li... > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > |
|
From: Javier de la T. <ja...@gm...> - 2006-11-16 17:58:33
|
Hi all, I am starting to wonder if it is necessary to keep separate the user and developers mailing lists for pywrapper. Right now it looks more like if we only use developers and this might give the impression that nothing is going on with pywrapper for users... This came to my mind while reading Peter last message. I would propose to merge the two mailing lists into one and if in the future we really see the need to separate devel and users we go for it... Does this make sense or is not really necessary to worry about this? Javi. |
|
From: Peter B. <p.w...@re...> - 2006-11-16 17:52:08
|
Dear All, I'm just getting to grips with PyWrapper so please be gentle with me! I've installed PyWrapper on my Kubuntu Edgy desktop (AMD3200 2Gb RAM) and have a few observations and questions: I've installed from an anonymous checkout using both the standard install script and to the system using apt etc - both seem to work fine. Unfortunately the instructions for using FastCGI do not work on my system - I think this is because Kubuntu packages Apache in an awkward way. I'll look at providing documentation at some point but for now I'll just use as a standalone server. Out of interest what is the distro of choice in the PyWrapper community? The next problem I have is that there is a considerable delay between running start_server.py and the server actually coming online (I've timed it to 3mins 10secs). Whilst in itself this isn't such a big deal (after all I'll only be (re)starting the server very occasionally once I've got everything live!) but I'm worried this is indicative of a problem. Can anyone give me their experiences on startup times? Once up and running the server seems very responsive most of the time but occasionally it can become very slow. I'm just working with the MySQL training database so it's just a standard installation. Using the Query Forms, it can happily return various requests but some times a search request (both DWC and ABCD) seems to stall the server. After this point the server stops responding for quite a long time until the connection times outs. Is this a CherryPy issue do you think or perhaps a problem with the version of MySQL / MySQLdb? Are most PyWrapper users running standalone servers or are they using FastCGI and Apache? Many thanks Peter |
7 messages has been excluded from this view by a project administrator.
