{23} Trac comments (3729 matches)

Results (2901 - 3000 of 3729)

← 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 →
Ticket Posixtime Author Newvalue
#559 1310126313000000 shevski I don't understand this one. It is older than 6 months so marking invalid.
#559 1310127694000000 dread Makes sense to me... Works for me too, so leaving closed.
#558 1283781883000000 pudo fixed in cset:2c4c43302f21
#556 1283340873000000 johnbywater Referencing ticket #547 has changed sprint.
#555 1283340873000000 johnbywater Referencing ticket #547 has changed sprint.
#554 1283340873000000 johnbywater Referencing ticket #547 has changed sprint.
#553 1283340874000000 johnbywater Referencing ticket #547 has changed sprint.
#552 1283340874000000 johnbywater Referencing ticket #547 has changed sprint.
#551 1283340866000000 johnbywater Referencing ticket #546 has changed sprint.
#550 1283340866000000 johnbywater Referencing ticket #546 has changed sprint.
#549 1283340866000000 johnbywater Referencing ticket #546 has changed sprint.
#548 1283340866000000 johnbywater Referencing ticket #546 has changed sprint.
#546 1286896167000000 anonymous [http://www.pokers.li Jeux de poker en ligne]
#546 1286896450000000 anonymous [http://www.bonus-pokers.eu Poker en ligne]
#546 1286896814000000 anonymous [http://www.salle-de-poker-legal.com Jouer au poker en ligne]
#544 1291638966000000 rgrp Duplicate of #672
#543 1311178918000000 thejimmyg Consolidation of caching has been moved in ticket #995.
#542 1283278896000000 wwaites Implemented with: * cset:2bbc186459cb * cset:eba23cc027e5 * cset:e89e0b82b24e * cset:943ed812e237
#541 1294924872000000 wwaites this is implemented with the cookie javascript technique. not so suitable for pages where content is radically differerent depending on the logged in user but for small bits like the logged in status works perfectly well, likewise for edit links.
#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...
#540 1302694845000000 dread Closing - all the suggestions have been implemented: squid instance and cache headers set for high traffic pages.
#539 1303118486000000 thejimmyg Old ticket, not sure exactly what it is referring to, closing.
#538 1294412635000000 thejimmyg Rufus, is this something you want to take on or shall we close the ticket as wontfix?
#538 1294414537000000 rgrp We don't use reports any more -- just the query module -- so closing as wontfix.
#537 1283325156000000 wwaites See #540 for a story about Varnish. Strongly favouring squid at this juncture.
#537 1288023097000000 dread Can this ticket be updated? Were any tasks listed here done? Anything remaining still planned?
#537 1311178929000000 thejimmyg Consolidation of caching has been moved in ticket #995.
#536 1286376029000000 dread I did this a few weeks ago.
#535 1283167040000000 rgrp Duplicate of #434
#534 1288002762000000 dread I fixed this a while back.
#533 1292957374000000 dread Not a current issue afaik.
#531 1283536676000000 pudo done: http://bitbucket.org/okfn/ckanextiati/src/tip/ckanext/iati/fixtures.py
#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
#529 1283536554000000 pudo at https://spreadsheets5.google.com/ccc?key=tuOtQjD0Psoqr1pWTS8EXZQ&hl=en#gid=0
#528 1283536475000000 pudo Done at http://iati.ckan.net
#527 1293097531000000 rgrp Just to note: did this relate to IATI or ...? Any way to add component and milestone?
#526 1320930201000000 dread Is this still relevant or can it be closed?
#526 1340626152000000 icmurray Won't fix as it's 20 months old, and no feedback on whether it's still relevant or not.
#525 1285595080000000 pudo As of now, PE creation can only be done by sysadmins. When opened to normal users, they will not be able to set the group type and thus moderation will be required of sysadmins.
#524 1285594971000000 pudo fixed as of cset:470d1e1c4460
#523 1283897688000000 pudo * Auth will be finished in #524. * PE write access etc. via standard API, compare ckanextiati:a02467cb67ba
#522 1285595317000000 pudo Still missing some internal authorization work but on the UI side, things are mostly functional. cf. http://bitbucket.org/okfn/ckanextiati/changeset/b2588091fa56 ff
#522 1287392999000000 pudo Has been fixed for quite some time.
#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)
#521 1283538342000000 pudo * still needs to have schema adapted a bit * work so far is at eu4:~/var/solr/iati/conf/schema.xml
#521 1283897124000000 pudo Schema has been adapted to suit IATI
#520 1283538080000000 pudo * http://bitbucket.org/okfn/iati/changeset/378431974c76 solr facets
#519 1283536828000000 pudo * Mostly implemented, still have to consider further cleanup.
#518 1282893844000000 pudo * Priority: 5 * Web user interface for publishing entities
#518 1283536932000000 pudo * Still needs "archive file" and "donors country" fields, PE questions to be answered.
#518 1283896718000000 pudo functional as of cset:ae4d4263b0c0 in ckanextiati
#517 1283897199000000 pudo See forms/iati, fixtures.py, fixtures.json as of ckanextiati: a02467cb67ba
#516 1288002933000000 dread Someone has fixed this.
#515 1302774253000000 dread This is now fixed in enh-1046-dictize-the-api. Both groups and packages return the location header.
#514 1282757391000000 dread Same as ticket:515
#513 1302774329000000 dread In enh-1046-dictize-the-api we remove the distinction of extras, so we can't do this.
#512 1294917121000000 dread Same as #513
#511 1297075354000000 thejimmyg There have been quite a lot of improvements, this is now OK.
#510 1282925375000000 dread Referencing ticket #509 has changed sprint.
#510 1292955569000000 dread Now setup - just need to check the cron fires ok.
#510 1294138332000000 dread Completed 21st Dec 2010.
#509 1285757116000000 dread Will Waites did this a couple of weeks agoWill Waites did this a couple of weeks ago
#509 1291734435000000 dread Story no longer required. Work to do is still described in #510
#508 1282822372000000 dread ultrastable branch created from 1.0.1 - version on dgu. Developing policy at wiki:BranchingPolicy
#508 1282908795000000 dread Policy discussed on list.
#507 1282909852000000 dread Done
#505 1288606561000000 dread Referencing ticket #504 has changed sprint.
#505 1298368280000000 dread Now complete
#503 1314031851000000 dread Relationships exist now on ckan.net. e.g. http://ckan.net/package/rkb-explorer-ibm No current DGU interest.
#502 1292586466000000 dread Not doing data4nr at the moment.
#501 1282563166000000 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
#500 1287747652000000 rgrp Looks like a duplicate of ticket:463 (also added by dread -- so hope I'm not making a mistake!)
#499 1296593038000000 thejimmyg Not on the SoR.
#498 1294412520000000 thejimmyg This is something that the Drupal team would need to do. There is no ability or requirement to embed the map widget into the CKAN search system yet.
#497 1294407705000000 thejimmyg Merged with #497
#497 1294407718000000 thejimmyg Sorry that should have been #496.
#496 1294407899000000 thejimmyg This would only apply to packages that had a HarvestedDcoument record (ie had been harvested). There are two approaches for this: * Build the capability to respond to CSW "GetCapabilities" and "Get Records" requests * Export to an existing CSW server to provide the mechanism for us
#496 1297684298000000 thejimmyg The latest plan after update with PP is as follows: * CKAN will have a CSW interface * OS GenoNetwork will use this interface to determine: * New documents * Modified documents * Removed documents * OS will then handle the serving back to the EU since GeoNetwork already implements the custom filters the EU may require (their docs are ambiguous). This means the creation of the CSW server extension is now a high priority but it only needs to know about documents in the harvested_documents table. I've already implemented a REST API to get the those documents (but depending on the implementation it may need changing).
#496 1299164106000000 thejimmyg Will has implemented this now and OS have confirmed their export to GeoNetwork works.
#490 1283770756000000 wwaites Presuming this is for INSPIRE compliance, support for Opensearch should be added
#489 1294414420000000 thejimmyg Which RDF service? Why does it need model events? Will, any ideas or shall I close it? Thanks.
#489 1294416189000000 wwaites We still do need something like this. Right now the rdf generation is a cron job that crawls the API. Really we want two things: * only generate RDF for those packages that have changed * enable multiple client/worker processes, potentially run by third parties, to generate different parts of the RDF description. For example, it is reasonable that we generate the DCat representation ourselves, however the voiD authors (DCat is generic, voiD is about RDF datasets in particular) want to generate the voiD-specific annotations themselves and contribute it back to augment the catalogue. Another example: group curators may also want to annotate packages in their group with group-specific metadata. Yet another example: checks on the coherence, availability, quality, openness, etc. of a package should be done from time to time or when a package changes, which can result in further annotations (see the curate tool). Because of the "third party" aspect we cannot do this with the internal package representation and the rabbit queue. Most likely it is feasible to do this by looking at the revisions in the API to get all changes since the last time a script was run in which case most likely the answer is, yes, there is nothing to do here and the ticket can be closed.
#488 1320930240000000 dread Not a current reqt.
#487 1291639404000000 rgrp Obsolete story type and looks like duplicate of #353 (and other parts of ticket:847)
#486 1291639321000000 rgrp This is a requirement ticket which we no longer support and a duplicate #847.
#485 1294411946000000 thejimmyg Merging with #371.
#484 1294417248000000 thejimmyg There isn't a catalogue web UI, just CKAN. I don't understand this, marking invalid. See instead #482.
#483 1294417216000000 thejimmyg There isn't a catalogue web UI, just CKAN. I don't understand this, marking invalid. See instead #482 and #484.
#482 1294417310000000 thejimmyg At some point we may want to introduce rate limiting on the CKAN API.
#482 1298284158000000 thejimmyg This is now 6 months old and there still doesn't seem to be a requirement for this. Marking wontfix and we can come back to it if it comes up again.
#481 1294248359000000 thejimmyg This is now implemented for DGU.
#480 1294411813000000 thejimmyg We are currently updating the specification and the servers this runs on.
#480 1300281551000000 thejimmyg This is complete (albeit with a different architecture).
#479 1282662526000000 rgrp Referencing ticket #462 has changed sprint.
#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.
#479 1288004211000000 dread Done
#478 1282662798000000 rgrp Referencing ticket #473 has changed sprint.
#477 1294411761000000 thejimmyg Duplicate of #476
#476 1294411741000000 thejimmyg Where did this requirement come from? Setting to wontfix for the timebeing. Feel free to re-open if there is a clear use case for this.
← 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 →
Note: See TracReports for help on using and creating reports.