| GitHub146 | [mantisbt] davidhicks force-pushed next from 38b904b to 306956d: http://git.io/t1IA8Q | 01:23 |
|---|---|---|
| GitHub146 | [mantisbt/next] Move config files to application/config directory. This will be out of the web tree once restructuring is complete. - Daryn Warriner | 01:23 |
| GitHub146 | [mantisbt/next] Move core files to application/core. The .htaccess file will not be needed as this will not be reachable - Daryn Warriner | 01:23 |
| GitHub146 | [mantisbt/next] Move Soap api to application/services/soap. - Daryn Warriner | 01:23 |
| *** Joins: Paul_46 (~IceChat09@cpc1-enfi15-2-0-cust580.hari.cable.virginmedia.com) | 03:52 | |
| dhx1 | Paul_46: :) | 04:21 |
| GitHub120 | [mantisbt] davidhicks pushed 1 new commit to next: http://git.io/P5rH5w | 04:30 |
| GitHub120 | [mantisbt/next] Replace plugin_lang_get with new gettext approach - David Hicks | 04:30 |
| Paul_46 | hi | 06:24 |
| Paul_46 | my mantisbt2 branch is slowly coming along nicely | 06:24 |
| dhx1 | Paul_46: can you push the branch to GitHub again? | 06:30 |
| Paul_46 | what does error: src refspec does nto match any mean? | 06:36 |
| Paul_46 | done | 06:38 |
| dhx1 | ok :) | 06:48 |
| dhx1 | have you been following 'next'? | 06:49 |
| Paul_46 | a little | 06:50 |
| Paul_46 | I dont like the idea of gettext atm | 06:50 |
| Paul_46 | at least not yet | 06:50 |
| dhx1 | any particular reasons? | 06:50 |
| Paul_46 | I think we need to tidy up other stuff first | 06:50 |
| Paul_46 | i.e. | 06:50 |
| Paul_46 | try and get some of the stuff moved to objects | 06:51 |
| Paul_46 | think about templates | 06:51 |
| dhx1 | I'm hesitant about objects and templates | 06:51 |
| Paul_46 | rather then change the language layer, then think about templates and decide we want a different layet | 06:51 |
| Paul_46 | i'm currently just seeing where I can take this branch | 06:51 |
| dhx1 | My attempt at using gettext is to provide a basis for proper localisation/internationalisation support when we get around to fixing the UI | 06:52 |
| dhx1 | if I had to propose a "template" system, it'd probably be a DOM object we manipulate within PHP using DOM function calls | 06:53 |
| dhx1 | ... where we try to avoid doing that wherever possible | 06:53 |
| Paul_46 | i'm just thinking more and more that if you look at mantis | 06:54 |
| Paul_46 | and some of the bugs that come in | 06:55 |
| Paul_46 | and that we fix | 06:55 |
| Paul_46 | some of them are due to the way we structure stuff atm | 06:55 |
| dhx1 | indeed | 06:55 |
| dhx1 | mostly it's due to having multiple ways of doing the same action in MantisBT | 06:55 |
| Paul_46 | so I don't mind taking a sledgehammer approach and seeing where I end up | 06:55 |
| dhx1 | SOAP API has different access checks than the standard HTML interface | 06:55 |
| dhx1 | etc | 06:55 |
| Paul_46 | yes | 06:55 |
| Paul_46 | [part of the reason i'd kinda like objects is such that it helps us define (Eventually) an interface | 06:56 |
| Paul_46 | i'd like to see soap api bascially be: | 06:56 |
| Paul_46 | function soap_get_user_name($user_id ) { | 06:56 |
| Paul_46 | return MantisUser($user_id)->get_username(); | 06:57 |
| Paul_46 | where as, atm, it's probably running it's own sql query :P | 06:57 |
| Paul_46 | to avoid the fact that the get username call in the html interface formats the username in bold text or something :P | 06:57 |
| dhx1 | I partially agree | 06:57 |
| dhx1 | but loading an entire MantisUser object from the database just to get the username is wasteful | 06:58 |
| Paul_46 | I partially agree :) | 06:58 |
| Paul_46 | there's a two fold question there | 06:59 |
| Paul_46 | atm, I suspect we do select * | 06:59 |
| Paul_46 | and cache | 06:59 |
| Paul_46 | you like the idea of doing select name | 06:59 |
| dhx1 | so I'm leaning more towards having a user_get_name($userID) function that is used whenever you only want to get a user name from an ID | 06:59 |
| Paul_46 | one could make the object lazy load data | 06:59 |
| dhx1 | hmmm | 06:59 |
| dhx1 | lazy load is too slow/cumbersome/complex | 07:00 |
| Paul_46 | however, my view is that we want to minimise db queries | 07:00 |
| dhx1 | I'd rather just load the whole object once | 07:00 |
| dhx1 | do we really need to minimise database queries? | 07:00 |
| Paul_46 | so if you are going to call user_get_name and then later on the page user_get_realname | 07:00 |
| Paul_46 | i'd say it's a 'bug' to call that as two queries | 07:00 |
| Paul_46 | i'd rather have | 07:00 |
| dhx1 | any decent SQL server will cache query results... | 07:00 |
| Paul_46 | a) select name, realname | 07:00 |
| Paul_46 | or select * | 07:00 |
| dhx1 | I agree | 07:00 |
| Paul_46 | sure but if the sql server isn't on the same box it's still a tcp roundtrip | 07:01 |
| dhx1 | which is why we still need a User object | 07:01 |
| dhx1 | for cases where we're working on just one user at a time and need to access many different fields | 07:01 |
| Paul_46 | and arguably if there's only 30 bytes of data in the column, it's probably less load on the sql server to get 30 bytes first then to get 4 bytes and 4 bytes later in two questions | 07:01 |
| dhx1 | actually -- that's debatable too in some ways | 07:01 |
| dhx1 | agreed | 07:01 |
| dhx1 | but we could easily do a query builder approach | 07:02 |
| dhx1 | create the query with all required fields | 07:02 |
| dhx1 | and then execute the query | 07:02 |
| dhx1 | and output that data to the user | 07:02 |
| dhx1 | it's not quite that easy though :( | 07:02 |
| Paul_46 | seperately, i've been working on some other projects for game i play | 07:03 |
| dhx1 | I'm thinking of redoing the Enum stuff next | 07:03 |
| Paul_46 | that use memcached to cache data | 07:03 |
| dhx1 | hmmm, memcached is still useful? | 07:03 |
| dhx1 | why can't the SQL server provide that caching for you? | 07:03 |
| dhx1 | it seems OK to use for data that doesn't need to meet ACID requirements | 07:04 |
| Paul_46 | i think it's a case of simplicity | 07:04 |
| Paul_46 | think about it | 07:04 |
| dhx1 | I don't see the point myself | 07:04 |
| Paul_46 | if you wrote some code that said | 07:04 |
| Paul_46 | select name whre id = 1 from mysql | 07:05 |
| dhx1 | I'd rather use a front end caching layer such as Varnish (microcaching) | 07:05 |
| Paul_46 | the mysql servers going to have to do some work | 07:05 |
| Paul_46 | check permissions etc | 07:05 |
| dhx1 | cache pages on the front end for 0.5 seconds to limit PHP being called at all to 2 times/second | 07:05 |
| Paul_46 | wheresa with memcached your basically going | 07:05 |
| Paul_46 | "gimme this id from ram" | 07:05 |
| Paul_46 | and getting back whatever you've stored | 07:06 |
| Paul_46 | so if that's a json/serialized object | 07:06 |
| Paul_46 | that's gonna be faster then going to mysql and building the object | 07:06 |
| dhx1 | SQL server cache will double check if the value has changed, permissions are still valid to access the data, etc | 07:06 |
| Paul_46 | microcaching is good for readonly data | 07:06 |
| dhx1 | so that is all you're avoiding | 07:07 |
| Paul_46 | yea, still my point is that's gonna be technically slower then the memcache check | 07:07 |
| dhx1 | a valid point in some cases :) | 07:07 |
| dhx1 | microcaching is good for pages served to anonymous users (read only) | 07:07 |
| Paul_46 | I was trying to work out if I had nginx setup right to do microcaching | 07:07 |
| Paul_46 | but then I realised | 07:07 |
| Paul_46 | well two things | 07:07 |
| dhx1 | which is the bulk of traffic to an open source bug tracker | 07:07 |
| Paul_46 | a) I couldn't work out whether i had the micro caching doing it :) | 07:07 |
| Paul_46 | b) I realised that the page content changes if your logged in, so probably shouldn't cache it :) | 07:08 |
| dhx1 | we'd have to redesign MantisBT to work with microcaching | 07:08 |
| dhx1 | CSRF tokens cannot exist on pages that are microcached (or else they quickly lose their security value) | 07:08 |
| Paul_46 | tbh, i'd kinda wonder if microcaching would work for a bug tracker | 07:08 |
| Paul_46 | i.e. | 07:08 |
| Paul_46 | microcaching is normally "lets store this page for a minute or so" right? | 07:09 |
| dhx1 | more like <1 second | 07:09 |
| dhx1 | the idea is that the user won't notice the effect of cachine | 07:10 |
| Paul_46 | yea, so you'd have to have a really busy bug tracker for it ever to kick in | 07:10 |
| Paul_46 | :) | 07:10 |
| dhx1 | *caching | 07:10 |
| dhx1 | but you can pump through 10,000 hits/second :) | 07:10 |
| dhx1 | right | 07:10 |
| dhx1 | still good for open source bug trackers that have bugs hit the front page of a popular website | 07:10 |
| dhx1 | funny bug reports, major security vulnerabilities, "how to do XYZ", etc | 07:11 |
| Paul_46 | the one thing i've found with the memcache thing | 07:11 |
| Paul_46 | is I think it does make a difference | 07:11 |
| Paul_46 | for example, the code i'm working on memcache's sql queries [ personally i'm not sure i like this as i'd rather cache objects etc] | 07:11 |
| Paul_46 | however, it'll take 10seconds to generate the page running the sql queries | 07:12 |
| Paul_46 | if you turn on the memcache caching, it does speed up | 07:12 |
| dhx1 | are you using PDO? | 07:13 |
| Paul_46 | this code doesn't | 07:14 |
| Paul_46 | looking at http://dev.mysql.com/doc/refman/5.1/en/query-cache.html | 07:14 |
| Paul_46 | "Be cautious about sizing the query cache excessively large, which increases the overhead required to maintain the cache, possibly beyond the benefit of enabling it. Sizes in tens of megabytes are usually beneficial. Sizes in the hundreds of megabytes might not be." | 07:14 |
| Paul_46 | --- | 07:15 |
| Paul_46 | Caching full queries only – Meaning it does not work for subselects, inline views, parts of the UNION. This is also common missunderstanding. | 07:15 |
| Paul_46 | ahh | 07:15 |
| Paul_46 | some of the code i know uses unions/subselects | 07:15 |
| Paul_46 | so maybe it's not caching | 07:15 |
| Paul_46 | Table level granularity in invalidation – If table gets modification all queries derived from this table are invalidated at once. | 07:16 |
| Paul_46 | yea right , ok | 07:16 |
| Paul_46 | this code basically is for a killboard | 07:16 |
| Paul_46 | so every 30 mintues or so, new data comes in | 07:16 |
| Paul_46 | == cache wiped | 07:16 |
| dhx1 | Paul_46: queries with UNION, etc will still be cached... in full | 07:17 |
| Paul_46 | nod | 07:17 |
| Paul_46 | whereas, with memcache, there's say 20,000 'corporations' | 07:17 |
| Paul_46 | those objects stay in cache all the time | 07:17 |
| Paul_46 | and it just updates the cache object when updating the db | 07:17 |
| dhx1 | if you're able to cache stuff for 30 minutes... great! | 07:17 |
| dhx1 | I'd be happy to cache stuff for 1 minute hah | 07:17 |
| dhx1 | we need to work out whether we need ACID compliance or whether it can be "eventually consistent" | 07:18 |
| Paul_46 | btw, also in same webpage: "It is not that fast Query Cache is fast compared to running the queries but it is still not as fast as specially designed systems such as memcached or local shared memory. " | 07:19 |
| Paul_46 | but then we know this | 07:19 |
| Paul_46 | the reason db's have query caches is to speed up common queries | 07:19 |
| Paul_46 | but if you specifically design to store something in ram only, it's well :) | 07:19 |
| dhx1 | I can see where memcached would be useful for MantisBT | 07:21 |
| Paul_46 | i'd probably store projects, users, permissions, config in memcached | 07:21 |
| Paul_46 | and probably let bugs/history hit db | 07:21 |
| dhx1 | but I wouldn't use it if SQL server cache or front end microcaching can take the load instead | 07:21 |
| dhx1 | not keen on that... | 07:22 |
| Paul_46 | that's where you'd probably see a nice performance gain | 07:22 |
| *** Quits: siebrand (~siebrand@5353A6DC.cm-6-4c.dynamic.ziggo.nl) (Quit: siebrand) | 07:23 | |
| *** Joins: siebrand (~siebrand@5353A6DC.cm-6-4c.dynamic.ziggo.nl) | 07:23 | |
| Paul_46 | i.e. you'd instantly have the username etc available | 07:25 |
| Paul_46 | but i'd still make the point of | 07:25 |
| Paul_46 | I wonder how many bug trackers get enough traffic | 07:25 |
| Paul_46 | to need that or microcaching | 07:26 |
| Paul_46 | :) | 07:26 |
| dhx1 | right :) | 07:26 |
| dhx1 | I don't like fixing problems that don't exist | 07:26 |
| Paul_46 | at the same time, if you got a user object, it would be trivial to allow that to be saved to ram/disk if required at some point | 07:27 |
| dhx1 | it'd be better to try and optimise our queries (and database design) before worrying about caching | 07:27 |
| Paul_46 | well I merged the bug_text tables together | 07:27 |
| Paul_46 | to get rid of the join | 07:27 |
| Paul_46 | again, that's partly on the basis it's easier to map to objects at that point | 07:28 |
| Paul_46 | i'm just really at the point of trying to take a fresh look at things | 07:28 |
| dhx1 | agreed on that merge | 07:28 |
| dhx1 | same | 07:29 |
| Paul_46 | i'm not really fussed if my branch<>next<>1.2 get diverged | 07:29 |
| Paul_46 | as thats just a case of going through | 07:29 |
| dhx1 | I'll probably cherry pick from your branch :) | 07:29 |
| Paul_46 | i've been cherry picking form yours/1.2 | 07:29 |
| Paul_46 | I think the main thing is, within a two months, we probably need to sit down and review what branches look like | 07:30 |
| dhx1 | yep | 07:31 |
| Paul_46 | the only thing I dont like is there's been some commits to do things like "add a new 'g_allow_permanent_cookie' config variable" | 07:32 |
| Paul_46 | in that particular one i'm thinking two things | 07:32 |
| Paul_46 | a) I'm getting to the point I dislike that we have 200000000 config's | 07:33 |
| dhx1 | I've been including everything from 'master' so 'next' can be merged back in easily | 07:33 |
| dhx1 | I could merge it right now in 5 seconds if I wanted to | 07:33 |
| dhx1 | it may be the case that some of this new functionality is removed in 'next' :) | 07:33 |
| dhx1 | a - agreed | 07:33 |
| Paul_46 | b) the additional of that config variable kinda makes me want to function the plugin framework idea, deprecate that value and go "you want that feature, make a authentication plugin" | 07:34 |
| Paul_46 | [and maybe even provide said plugin] | 07:34 |
| dhx1 | I feel like I'm being forced by MantisBT into redesigning custom fields, enumeration types, etc | 07:34 |
| dhx1 | the more I think about it the more I prefer these definitions occur within .php files (not in the database) | 07:34 |
| Paul_46 | I reverted some commit locally | 07:35 |
| dhx1 | party because of gettext benefits of being able to parse raw .php files | 07:35 |
| Paul_46 | that added a extra text field to some custom field table | 07:35 |
| Paul_46 | you know custom fields have 'display on report', 'display on open' etc? | 07:36 |
| dhx1 | yes | 07:36 |
| dhx1 | I'd rather they didn't... | 07:36 |
| Paul_46 | and i'm pretty sure we had a long discussion at time about whether we should store that information in table | 07:36 |
| Paul_46 | or as seriliazed data etc | 07:36 |
| Paul_46 | given way things are going now a days | 07:36 |
| dhx1 | I'd rather we didn't store custom field definitions in the database | 07:37 |
| Paul_46 | i'm kinda thinking, i'd rather have that stored as some json encoded string [yes, json is slower for one of decode/encode then serialize] | 07:37 |
| Paul_46 | oh, I think i see what your saying | 07:37 |
| dhx1 | I'd rather we have something like: | 07:38 |
| Paul_46 | are you saying if someone wants a custom field exactly 20 characters long, you have a. php file defining that? | 07:38 |
| dhx1 | fields/Reporter.php | 07:38 |
| dhx1 | fields/Resolution.php | 07:38 |
| dhx1 | etc | 07:38 |
| dhx1 | and each file provides all the definitions/etc needed to make the field work | 07:38 |
| dhx1 | right | 07:38 |
| dhx1 | OO/traits could be used to inherit from other classes | 07:39 |
| dhx1 | so it'd be easy for users to take an existing definition and slightly modify it | 07:39 |
| Paul_46 | well, i'm kinda 'against' that or well | 07:39 |
| Paul_46 | fields/file.xml/json ==> 'ok' | 07:39 |
| Paul_46 | i'm not sure aobut .php as that kinda implies end users need to code to do stuff | 07:40 |
| dhx1 | the main reason I'm looking at this approach is for internationalisation reasons (it's better to store custom field names, etc in .php files so gettext can get to them) | 07:40 |
| dhx1 | gettext methods for translating custom field details allows us to provide translation hints, pluralisation support, etc | 07:40 |
| Paul_46 | thing is, that's not user friendly :) | 07:40 |
| Paul_46 | for example, at work, i've allowed my boss to add some custom fields | 07:41 |
| Paul_46 | he doesn't do coding | 07:41 |
| dhx1 | we can provide a GUI frontend to make it easy for users to create new fields... | 07:41 |
| Paul_46 | then you've got gui writing .php files, which could in theory be a risk | 07:41 |
| Paul_46 | however, tbh, even if you had | 07:41 |
| Paul_46 | fields/Reporter.json for example, you could still translate it later on | 07:42 |
| Paul_46 | more importantly | 07:42 |
| Paul_46 | have you ever looked the 'thebuggenie'? | 07:42 |
| dhx1 | looking now | 07:42 |
| Paul_46 | http://issues.thebuggenie.com/ | 07:42 |
| dhx1 | looks nice, thanks for the link | 07:45 |
| dhx1 | I don't agree with some of their UI decisions | 07:45 |
| Paul_46 | nod | 07:45 |
| dhx1 | for instance, tabbed Comments, Attachments, etc | 07:46 |
| Paul_46 | at the same time, i'd probably rather look at that then some bits of mantis | 07:46 |
| dhx1 | rather than just a long linear page | 07:46 |
| Paul_46 | ) | 07:46 |
| GitHub18 | [mantisbt] siebrand pushed 1 new commit to master-1.2.x: http://git.io/OA1B6A | 07:46 |
| GitHub18 | [mantisbt/master-1.2.x] Localisation updates from http://translatewiki.net. - Siebrand Mazeland | 07:46 |
| Paul_46 | actually | 07:46 |
| Paul_46 | if you think about it | 07:46 |
| dhx1 | siebrand: thanks :) | 07:47 |
| Paul_46 | the tab stuff is probably more user friendly | 07:47 |
| dhx1 | Paul_46: it's hiding content behind mouse clicks :( | 07:47 |
| Paul_46 | i'd probably put the attachments/comments on first page | 07:47 |
| Paul_46 | then hide | 07:47 |
| Paul_46 | or well | 07:47 |
| Paul_46 | having our bughistory hidden | 07:47 |
| dhx1 | in UI terms, "discoverability" isn't very high | 07:48 |
| Paul_46 | would be a good thing | 07:48 |
| Paul_46 | i'm not sure about hiding related issues etc | 07:48 |
| dhx1 | these are things which user CSS stylesheets can override (replacing a lot of our bad settings!) | 07:48 |
| Paul_46 | but as a whole | 07:48 |
| Paul_46 | http://issues.thebuggenie.com/thebuggenie/issues/new/bugreport | 07:49 |
| Paul_46 | I like that | 07:49 |
| dhx1 | issue history is very important to show | 07:49 |
| Paul_46 | wysiwtg wiki editor | 07:49 |
| dhx1 | I'm not sure whether we want to keep it in a separate table | 07:49 |
| dhx1 | or mix it in with the comments (my preference) | 07:49 |
| dhx1 | there are some other ideas I'd like to look at including: | 07:50 |
| Paul_46 | i'd like to come up with a mobile version of mantis in core | 07:50 |
| dhx1 | * bugs don't have owners (reporters) -- a bug will often affect more than one user and they can work together collaboratively to describe and fix the issue | 07:51 |
| dhx1 | * formal state machine implementation of workflows | 07:52 |
| dhx1 | * integration with mailing lists (have you used debbugs?) | 07:52 |
| dhx1 | * pick-n-mix workflows/field types/etc that come bundled with MantisBT by default... administrations can choose different development models in a single click | 07:53 |
| dhx1 | * full text search | 07:54 |
| dhx1 | * more emphasis on graphical representations (relationship graphs, critical path analysis, statistic plots, etc) | 07:55 |
| dhx1 | ... all aspirational 2030 goals of course :) | 07:55 |
| Paul_46 | nod | 07:56 |
| Paul_46 | :) | 07:56 |
| dhx1 | on a different matter, have you used Firefox's new 3D HTML display? | 07:58 |
| Paul_46 | no? | 07:58 |
| Paul_46 | whats this | 07:58 |
| dhx1 | Tools -> Web Developer -> Inspect -> 3D (M) | 07:59 |
| dhx1 | it shows the layers of a web page (nesting) in 3D | 07:59 |
| dhx1 | mantisbt.org/bugs has 2 logos on top of each other in different layers | 08:00 |
| dhx1 | perhaps that's just how this 3D view renders it sorry | 08:01 |
| Paul_46 | kinda intersting though | 08:02 |
| Paul_46 | anyway, main thing I want atm is a free opensource html5 layer for mantis | 08:03 |
| Paul_46 | :) | 08:03 |
| dhx1 | new UI? | 08:04 |
| Paul_46 | I want itouch version :P | 08:04 |
| Paul_46 | so I can use it at work easily | 08:04 |
| dhx1 | ah :) | 08:05 |
| Paul_46 | hoping to find some work time for mantis soon | 08:05 |
| Paul_46 | we just finished windows 7 deployment prettyy much | 08:05 |
| Paul_46 | boss is away for a week in may/june | 08:05 |
| Paul_46 | forget which | 08:05 |
| Paul_46 | i have ~50-60 open issues in mantis at work | 08:06 |
| Paul_46 | which is down from >100 | 08:06 |
| Paul_46 | and a whole bunch of those 50 are just sitting there | 08:06 |
| dhx1 | :) | 08:06 |
| Paul_46 | for example, one was 'lets try and install atmosphir' - which is some game thing that's got mentioned as maybe being educational | 08:07 |
| Paul_46 | but from what I can tell, it's dieing a death | 08:07 |
| Paul_46 | i.e. they went offline for a week or two a month ago | 08:07 |
| Paul_46 | and restored website/forum back 6 months | 08:07 |
| Paul_46 | the app downloads but won't run propelry for me | 08:07 |
| Paul_46 | the guy running it says new dev team coming on in may/june | 08:08 |
| Paul_46 | and yet, some of the "old staff" on forums are like posting "yea, sod this, we're off" :) | 08:08 |
| Paul_46 | so that's 1 of 50 that isn't going anywhere | 08:09 |
| Paul_46 | :) | 08:09 |
| dhx1 | hah | 08:09 |
| dhx1 | argggh | 08:25 |
| dhx1 | history_localize_item with plugin fields is an ugly problem | 08:25 |
| dhx1 | after a plugin is uninstalled, localisation for plugin history entries becomes unavailable | 08:26 |
| Paul_46 | I still think we need to take a step back :) | 08:26 |
| dhx1 | this is actually quite an ugly problem... how do we store history of a bug such that it is usable even after the plugin is uninstalled | 08:28 |
| dhx1 | I do have a solution but it's a bit of work | 08:28 |
| Paul_46 | well, the question would be if a lpugin gets removed, should the histroy get removed | 08:29 |
| dhx1 | Solution #1: If the plugin is removed then all the data associated with it (including history) is removed | 08:29 |
| dhx1 | Solution #2: When a plugin is installed it updates a user-configurable text domain that is permanently moved around with the installation | 08:31 |
| dhx1 | both approaches are bad... but I can't see an alternative ;/ | 08:32 |
| dhx1 | solution (2) essentially leaves part of the plugin behind "forever" | 08:32 |
| dhx1 | I prefer solution (1) on the basis that it promotes a clear separation of duties between MantisBT core and plugins | 08:34 |
| Paul_46 | disabling/enabling plugin and uninstalling are two different things remember :) | 08:34 |
| dhx1 | yeah | 08:35 |
| Paul_46 | in fact, thinking about it, what your partly describing may be something i'd thought about in terms of logging/notification | 08:35 |
| dhx1 | true | 08:35 |
| dhx1 | same problem | 08:35 |
| Paul_46 | i.e. atm, we trigger an event and let plugin do whatever | 08:35 |
| dhx1 | because 'history' is really just a log | 08:35 |
| Paul_46 | i'd like to [for notifications], let plugin register a notification hook | 08:35 |
| Paul_46 | at that point, uninstalling would let us see in core 'did this plugin have any hooks registered' | 08:36 |
| dhx1 | yep, item #59 on my TODO list is to add a new notification subsystem to MantisBT :) | 08:36 |
| Paul_46 | if yes, there should be a cleanup function | 08:36 |
| Paul_46 | 59? | 08:36 |
| Paul_46 | random number? :P | 08:36 |
| dhx1 | (or some other high number :P) | 08:36 |
| Paul_46 | hehe | 08:36 |
| dhx1 | I wonder if anyone has provided localised logging before... hmm | 08:37 |
| dhx1 | we could store a log for each locale :P | 08:37 |
| Paul_46 | how about 'no' | 08:37 |
| dhx1 | I'm actually keen to rethink "history" | 08:39 |
| Paul_46 | this is partly where i like my 'objects' approach | 08:40 |
| dhx1 | perhaps we should have a "bug_revisions", "project_revisions", "user_revisions", etc table for each MantisBT table | 08:40 |
| Paul_46 | i'm assuming it'll need to be rewritten | 08:40 |
| Paul_46 | or well, re-organised | 08:40 |
| Paul_46 | but it gives option to go through code base and move code around :P | 08:40 |
| Paul_46 | if you noticed, I'd move all of the manage_* stuff in my branch to a /manage bit | 08:41 |
| Paul_46 | on the basis that if we do a new UI for end users | 08:41 |
| Paul_46 | we should probably work on the front end side first | 08:41 |
| Paul_46 | and if admin bit stayed with old api | 08:41 |
| Paul_46 | that would be fine | 08:41 |
| Paul_46 | but by seperating it out, it's easier to track how many pages we've got and what they do ;p | 08:42 |
| dhx1 | yeah | 08:43 |
| *** Quits: dhx1 (~anonymous@60-242-247-232.static.tpgi.com.au) (Quit: Leaving) | 17:48 | |
| *** Joins: giallu (~giallu@fedora/giallu) | 18:16 | |
| *** Quits: Paul_46 (~IceChat09@cpc1-enfi15-2-0-cust580.hari.cable.virginmedia.com) (Quit: I used to think I was indecisive, but now I'm not too sure.) | 19:05 | |
| *** Quits: giallu (~giallu@fedora/giallu) (Ping timeout: 276 seconds) | 19:44 | |
| *** Quits: sdfjkljkdfsljkl (~sdfjkljkd@static.96.23.63.178.clients.your-server.de) (Remote host closed the connection) | 20:00 | |
| *** Joins: sdfjkljkdfsljkl (~sdfjkljkd@static.96.23.63.178.clients.your-server.de) | 20:00 | |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!