{23} Trac comments (3729 matches)

Results (501 - 600 of 3729)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Ticket Posixtime Author Newvalue
#445 1282662530000000 rgrp Referencing ticket #477 has changed sprint.
#443 1282662560000000 rgrp Referencing ticket #457 has changed sprint.
#461 1282662564000000 rgrp Referencing ticket #454 has changed sprint.
#468 1282662774000000 rgrp Referencing ticket #467 has changed sprint.
#470 1282662774000000 rgrp Referencing ticket #467 has changed sprint.
#469 1282662778000000 rgrp Referencing ticket #471 has changed sprint.
#475 1282662794000000 rgrp Referencing ticket #472 has changed sprint.
#478 1282662798000000 rgrp Referencing ticket #473 has changed sprint.
#426 1282667892000000 dread Referencing ticket #422 has changed sprint.
#466 1282723866000000 dread As mentioned yesterday, I'm not convinced this is the best way to achieve the actual requirement, which is to access the API securely, and we should discuss this further.
#441 1282724509000000 dread Comment from pudo: Apache version is documented here: http://knowledgeforge.net/okfn/tasks/ticket/466
#501 1282724566000000 dread Good thinking - see previous ticket on this: ticket:441
#441 1282724585000000 anonymous Comment from pudo: CKAN should have a read-only maintenance mode with a nice little banner on all pages, appropriate REST messages etc. Bonus points if this is triggered via an environment variable and thus can be triggered by the surrounding apache.
#465 1282724701000000 dread This was an idea, to be able to monitor users overloading. It may not be required though.
#443 1282735925000000 dread Now produces daily dump in ~/dumps. Was running as root, not user. Previously it was updating ONS data but not dump because of path issues of being root. Serving files using Apache file index. Added docs for database dumping. Cost: 2h
#514 1282757391000000 dread Same as ticket:515
#423 1282812768000000 dread Examples for creating packages with curl are now in the API docs.
#508 1282822372000000 dread ultrastable branch created from 1.0.1 - version on dgu. Developing policy at wiki:BranchingPolicy
#331 1282833125000000 dread CKAN timestamps should not be in a timezone, since when the clock goes back, it could cause problems for vdm. But there may be cases when CKAN is running on a machine that needs the clock set for a particular country (say for a front-end running on the same machine), and so vdm should be changed to create timestamps using UTC specifically (rather than add a timezone, since a mixture of timezones won't sort). And when we display it (or reply to a request) we convert it to the local timezone, as suggested in the description.
#521 1282893545000000 pudo Ability to search over the IATI metadata stored about the IATI records that have been registered. * Priority: 5 (may merge into 1 to some extent)
#518 1282893844000000 pudo * Priority: 5 * Web user interface for publishing entities
#530 1282899463000000 pudo The core of the COI/data.gov.uk standard seems to look like: Identifier Title Abstract Department Contact Contact e-mail Licence Resource format Resource URL Resource ID Publisher And the IATI-specific ones we'd want are: Publishing Entity: Publishing Entity Type: (Donor, Recipient, Community Data..) Donor Country Activity period: Verification status: enumeration of statuses (checked, not checked etc) Resource links: to the actual IATI record Number of activities: ... Date record updated: Date data updated: License: Need this field even if it may be a standard license So naively mashing these together, we get something like: Identifier Title Abstract Donor Country Publisher Publisher Type Verification Status Department Contact Contact e-mail Licence Resource format Resource URL Resource ID Activity period Number of activities Date record updated Date data updated
#508 1282908795000000 dread Policy discussed on list.
#222 1282909280000000 dread Done already.
#421 1282909772000000 dread Done
#507 1282909852000000 dread Done
#424 1282919429000000 dread Done in: https://trac.dataco.coi.gov.uk/projects/datagov/ticket/496#comment:2
#479 1282920017000000 dread Still discussing. Current thinking that the apache file listing would easiest be opened up together with CKAN read-only web i/f.
#466 1282921608000000 dread We've agreed that we need another header for this, although it's not clear that it needs to be configurable. We could just accept Authorization OR the new one.
#459 1282921783000000 dread I've now fixed this. default: 1.1 metastable: 1.1 stable: 1.1 / 1.0.2 (two heads) ultrastable: 1.0.2
#426 1282925305000000 dread No responses unfortunately - maybe they are fine!
#510 1282925375000000 dread Referencing ticket #509 has changed sprint.
#427 1283165089000000 dread Posting a new package is done. Just licenses to explain.
#422 1283165156000000 dread Closed by mistake - task remains.
#535 1283167040000000 rgrp Duplicate of #434
#318 1283179768000000 wwaites CO may not realise the implications when they said it was low priority. The implication of this lack of validation is that it is impossible to generate valid URIs in the RDF which means it cannot be imported by Talis. So until there is a solution to this, no RDF catalog.
#433 1283183548000000 wwaites changed datapkg_sources to datapkg_index and updated to work with the new changes to how the downloader works.
#434 1283189807000000 rgrp Looking at stack trac clear this was an issue with genshi/babel and i18n. Net search led to http://trac.edgewall.org/ticket/9171 which confirmed this. Fact that error was on every page when logged in suggested this was a string in template showing up on log in. Quick search confirmed suspicion ('You are logged in as' string) and fix in http://bitbucket.org/bboissin/ckan-i18n/changeset/8e0c25102cc0
#542 1283278896000000 wwaites Implemented with: * cset:2bbc186459cb * cset:eba23cc027e5 * cset:e89e0b82b24e * cset:943ed812e237
#540 1283324947000000 wwaites Cut-and-paste from ckan-discuss: I had a look at Varnish and I agree that the configuration language is complicated. In fact by default Varnish disregards cache control headers and in general behaves in a very standards non-compliant way. I have no doubt that it is very fast -- if you are willing to spend the efford to customise its configuration for the exact layout of pages and headers and such that each web site it is going to be used with will use. In other words, there is a large administrative burden. So I decided to change tack and see where the Squid proxy has gotten to in the decade or so since I last met it. Squid is a general purpose caching proxy that can be configured as an http accelerator. The configuration is simple. You tell it where your web servers are for which sites. The web servers make sure to set the cache control headers appropriately. Here are some results from my testing, against http://de.ckan.net/package/list?page=B which is an example of a slow page. Except for the first, which only did 100 requests, the tests were set to 8 simultaneous connections and a total of 1000 requests. {{{ No caching of any kind: Requests per second: 0.44 [#/sec] (mean) Beaker Cache (filesystem): Requests per second: 43.16 [#/sec] (mean) SQUID setting cache control headers correctly: Requests per second: 421.33 [#/sec] (mean) }}} The results are clear. Using the application cache is about 100 times faster than doing nothing. Using squid is about 1000 times faster. (Doing both wouldn't necessarily help very much). I'm sure we could squeeze a bit more performance out of it if we used Varnish, but probably not an order of magnitude and I don't think it is worth the administrative burden. If we set up a production Squid instance (or farm), with a bare minimum of work it can cache for any number of sites, not just CKAN. For the python coders, here's what you have to do to set the headers properly so that squid will cache the page: {{{ del response.headers["Pragma"] del response.headers["Cache-Control"] from time import gmtime, strftime response.headers["Last-Modified"] = strftime("%a, %d %b %Y %H:%M:%S GMT", gmtime()) response.cache_expires(seconds=3600) }}} A further advantage is that the *browsers* will also understand these cache-control headers and do their own caching - just setting them properly without even using Squid should result in some subjective performance improvements. That's all for now, I suggest we dedicate a machine to just running squid, the more RAM the better and big discs are good, and put it between the world and the ckans. Oh, and comb through the controllers setting the headers correctly where appropriate...
#537 1283325156000000 wwaites See #540 for a story about Varnish. Strongly favouring squid at this juncture.
#548 1283340866000000 johnbywater Referencing ticket #546 has changed sprint.
#549 1283340866000000 johnbywater Referencing ticket #546 has changed sprint.
#550 1283340866000000 johnbywater Referencing ticket #546 has changed sprint.
#551 1283340866000000 johnbywater Referencing ticket #546 has changed sprint.
#554 1283340873000000 johnbywater Referencing ticket #547 has changed sprint.
#555 1283340873000000 johnbywater Referencing ticket #547 has changed sprint.
#556 1283340873000000 johnbywater Referencing ticket #547 has changed sprint.
#552 1283340874000000 johnbywater Referencing ticket #547 has changed sprint.
#553 1283340874000000 johnbywater Referencing ticket #547 has changed sprint.
#528 1283536475000000 pudo Done at http://iati.ckan.net
#529 1283536554000000 pudo at https://spreadsheets5.google.com/ccc?key=tuOtQjD0Psoqr1pWTS8EXZQ&hl=en#gid=0
#531 1283536676000000 pudo done: http://bitbucket.org/okfn/ckanextiati/src/tip/ckanext/iati/fixtures.py
#519 1283536828000000 pudo * Mostly implemented, still have to consider further cleanup.
#518 1283536932000000 pudo * Still needs "archive file" and "donors country" fields, PE questions to be answered.
#520 1283538080000000 pudo * http://bitbucket.org/okfn/iati/changeset/378431974c76 solr facets
#521 1283538342000000 pudo * still needs to have schema adapted a bit * work so far is at eu4:~/var/solr/iati/conf/schema.xml
#490 1283770756000000 wwaites Presuming this is for INSPIRE compliance, support for Opensearch should be added
#558 1283781883000000 pudo fixed in cset:2c4c43302f21
#518 1283896718000000 pudo functional as of cset:ae4d4263b0c0 in ckanextiati
#521 1283897124000000 pudo Schema has been adapted to suit IATI
#517 1283897199000000 pudo See forms/iati, fixtures.py, fixtures.json as of ckanextiati: a02467cb67ba
#523 1283897688000000 pudo * Auth will be finished in #524. * PE write access etc. via standard API, compare ckanextiati:a02467cb67ba
#562 1284063574000000 pudo fixed by ww by upgrading python-openid
#576 1284212162000000 wwaites * cset:9b1255e02e5e removes a reference to Package.c which is deprecated even in 0.4 * cset:d7e583948c95 wraps the session creation in if/else block on SQAlchemy version as the default behaviours and options have changed Unit Tests appear to work as before... Boy do they take a long time to run...
#576 1284215009000000 wwaites cset:7a04e78cec97 ''pool_threadlocal=True'' is no longer the default with 0.5. Setting it to ''False'' (the default) causes unit tests to hang. So explicitly set it to ''True'' to retain compatibility. It is an open question whether this is the ''correct'' setting, the defaults were changed as apparently they led to surprising behaviour. One hopes that our unit tests have already eliminated any such surprises.
#582 1284216078000000 johnbywater Referencing ticket #491 has changed sprint.
#583 1284216078000000 johnbywater Referencing ticket #491 has changed sprint.
#584 1284216078000000 johnbywater Referencing ticket #491 has changed sprint.
#585 1284216078000000 johnbywater Referencing ticket #491 has changed sprint.
#586 1284216078000000 johnbywater Referencing ticket #491 has changed sprint.
#587 1284216078000000 johnbywater Referencing ticket #491 has changed sprint.
#588 1284216104000000 johnbywater Referencing ticket #492 has changed sprint.
#589 1284216104000000 johnbywater Referencing ticket #492 has changed sprint.
#590 1284216104000000 johnbywater Referencing ticket #492 has changed sprint.
#591 1284216120000000 johnbywater Referencing ticket #493 has changed sprint.
#592 1284216120000000 johnbywater Referencing ticket #493 has changed sprint.
#593 1284216137000000 johnbywater Referencing ticket #494 has changed sprint.
#594 1284216137000000 johnbywater Referencing ticket #494 has changed sprint.
#595 1284216137000000 johnbywater Referencing ticket #494 has changed sprint.
#596 1284216140000000 johnbywater Referencing ticket #495 has changed sprint.
#597 1284216140000000 johnbywater Referencing ticket #495 has changed sprint.
#599 1284216189000000 johnbywater Referencing ticket #598 has changed sprint.
#600 1284216189000000 johnbywater Referencing ticket #598 has changed sprint.
#601 1284216189000000 johnbywater Referencing ticket #598 has changed sprint.
#602 1284219570000000 johnbywater Referencing ticket #567 has changed sprint.
#603 1284219570000000 johnbywater Referencing ticket #567 has changed sprint.
#604 1284219570000000 johnbywater Referencing ticket #567 has changed sprint.
#605 1284219570000000 johnbywater Referencing ticket #567 has changed sprint.
#608 1284219588000000 johnbywater Referencing ticket #577 has changed sprint.
#609 1284219588000000 johnbywater Referencing ticket #577 has changed sprint.
#606 1284219594000000 johnbywater Referencing ticket #578 has changed sprint.
#607 1284219594000000 johnbywater Referencing ticket #578 has changed sprint.
#610 1284219601000000 johnbywater Referencing ticket #569 has changed sprint.
#611 1284219601000000 johnbywater Referencing ticket #569 has changed sprint.
#612 1284219601000000 johnbywater Referencing ticket #569 has changed sprint.
#613 1284219601000000 johnbywater Referencing ticket #569 has changed sprint.
#614 1284219601000000 johnbywater Referencing ticket #569 has changed sprint.
#615 1284219609000000 johnbywater Referencing ticket #570 has changed sprint.
#616 1284219609000000 johnbywater Referencing ticket #570 has changed sprint.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Note: See TracReports for help on using and creating reports.