thekorn> it sucks, maybe. but do we need a new API for this, that's what I'm not sure about <seiflotfy> thekorn, u can see mhr3 and kamstrup got into the details of it <seiflotfy> they wrote the whoel api actually <m4n1sh_> seiflotfy: look into #ubuntu-classroom * mvo has quit (Quit: Ex-Chat) <RainCT> thekorn: what we should really add is AddBlacklistRule and DeleteBlacklistRule <thekorn> RainCT: yeah, <thekorn> after reading this bug, I tend to agree that we need some changes <thekorn> mikkel's proposal seems close to perfect to me <thekorn> so, whoever what's to work on it, should start with some paperwork, <thekorn> we are not ready to do the implementation yet <seiflotfy> thekorn, AFAIK m4n1sh is on it <seiflotfy> thekorn, also m4n1sh will do the implementation of it and propose it for merge <seiflotfy> he is very good with python <seiflotfy> maybe better than you :P <m4n1sh_> seiflotfy: dont set the expectations too high <thekorn> I'm sure he is. <seiflotfy> m4n1sh, its marketing :P <m4n1sh_> yeah. I was going through the code. The progress is slow as I am also on zg-sharp packaging and fixing the issues with meebey <thekorn> but I would like to design it properly first, <thekorn> to avoid extra roubndtrips of work <m4n1sh_> thekorn: sure! <m4n1sh_> seiflotfy: fuck man. OMG question on #ubuntu-classroom <seiflotfy> thekorn, lets use the first draft from mikkel <m4n1sh_> seiflotfy: over to classroom <thekorn> seiflotfy: why? <thekorn> does it cover all possible usecases of the blacklist feature * RainCT doesn't like kamstrup's proposal of having names for them <seiflotfy> RainCT, why not <thekorn> haha, that's actually the only thing I *like* about this proposal ;) <seiflotfy> thekorn, +1 <RainCT> because it's not necessary and may cause conflicts between apps who have the same rule with different names (so one says it's enabled and another one it isn't) <m4n1sh_> thekorn: RainCT seiflotfy I like kamstrup idea <seiflotfy> thekorn, whats up we have been getting along much better lately <seiflotfy> we tend to agree on stuff <seiflotfy> that is new to me <RainCT> what could be nice is a free form string for users to write their own name/description for the rule and maybe a boolean to enable/disable it (although i'm not sure if this later thing should really be in ZG or be a GUI thing) <thekorn> RainCT: if we set a naming convention, which is clearly defined somewhere, than it should be perfectly ok <RainCT> no, there is no naming convention for blacklists <thekorn> say who? <thekorn> says <RainCT> Me. <thekorn> ah ok. <RainCT> The Blacklist Management GUI would just resort to using unique IDs for user-defined stuff, which would be completely meaningless. <thekorn> in fact, in mikkels proposal the names are free form strings * meebey leaves work <RainCT> And the private browsing example isn't something which should be handled by blacklist but by the epiphany plugin itself <RainCT> and if you want to disable it centralized you can do it over the DataSourceRegistry and then the epiphany plugin is told it's been disabled <thekorn> ok, as you can all see, there needs to be alot of discussion <RainCT> ^^ <thekorn> so I don't expect we can do a change of the BL API until end of this year <thekorn> and as it seems that people consider the BL featur as important <seiflotfy> thekorn, we can work it off iteratively in a private branch <thekorn> people == our user <seiflotfy> until we feel comfortable with it <seiflotfy> so maybe wokring on ti now is a good idea * kep ([email protected]) has joined #zeitgeist <RainCT> So this will be the new Origin discussion, until I get tired of it and say "do whatever you want" and we have the ORM experience all over again? * RainCT hides <kep> hi <thekorn> RainCT: that's exactly the problem <RainCT> Hey kep <kep> I am new to IRC chat <thekorn> hi kep <kep> can you tell me iz this a zeitgeist chat room <kep> and where are you from if so <thekorn> RainCT: and this is why the approach "code until noone complains" is bad <RainCT> kep: Yes, but another Zeitgeist (http://zeitgeist-project.com/) <seiflotfy> thekorn, actually i dont mind it <kep> can you give me more info <kep> I am from Bulagaria <kep> and I am just finding some info on IRC so I can find ppl <seiflotfy> thekorn, well having some code that is better than the current one is always an option <seiflotfy> i think we know what we have now is not working <seiflotfy> and what kamstrup suggested is a better solution although not perfect <thekorn> seiflotfy: but we are not there yet to understand what is better <seiflotfy> with the high demand i think its clear we need to work on it <seiflotfy> and working code samples is never a bad idea <seiflotfy> AFAIK you are more convinced when you see working code <thekorn> I disagree <seiflotfy> thekorn, explain please <thekorn> design happens on paper, and not in code <thekorn> and it's about designing a feature <thekorn> seiflotfy: please remember all the wiki work, over weeks which was done by us to define our current DBUS api <thekorn> the only thing which speeded things up was the in person meeting of us at the hackfest <seiflotfy> thekorn, but the real paper work happend after severa literations over the blacklist <seiflotfy> by oging over several iterations we defined what out requirments are <seiflotfy> we can not do that with only one implementation <seiflotfy> we need several (not public but internal private that we can work with) <thekorn> wow, that's a very expensive way of doing work <thekorn> but hey, if you (or m4n1sh_ ) wants to work like that, that's fine with me, of course <seiflotfy> thekorn, depends i think we need to define a some software engineering process for each module <m4n1sh_> thekorn: agile? <seiflotfy> AFAIK zeitgeist is using a more agile development method <seiflotfy> m4n1sh, u can read my mind <seiflotfy> :) <thekorn> agile != thousand coding iterations <seiflotfy> thekorn, what u r suggesting here is us to use a more V model approach on the whole issue <mhr3> i remember zg having very odd dbus interface <mhr3> so it won't be the first time that some api changed <mhr3> and blacklist api isn't that crucial as the "main" one <seiflotfy> mhr3, the main stands though <seiflotfy> thekorn, AFAIK agile is an iterative process :) <m4n1sh_> seiflotfy: it is <seiflotfy> An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.[8] Multiple iterations may be required to release a product or new features. <RainCT> mhr3: but we are talking about extension in trunk, which are as important as zeitgeit's API itself <seiflotfy> (wikipedia) <seiflotfy> RainCT, ok u got me there <mhr3> seiflotfy, i wanted to say that zg seems to have iterative design process in place for some time <seiflotfy> RainCT, that is why i proposed doing the ne w blacklist in a branch <seiflotfy> and ofr us to use it over time <seiflotfy> and release it when we r done iterating and established a wiki for it * jamalta has quit (Remote host closed the connection) <RainCT> You're free to have as many branches as you want :) <seiflotfy> mhr3, yes but dont mix up between iterative design process and actual development process <RainCT> (To use it you need a GUI first though) <thekorn> but before you start, you should define a goal, to understand when a branch is good enough <seiflotfy> thekorn, i agree <mhr3> still, what matters are users of said blacklist api, how many are there? i think the number is very small <seiflotfy> but <m4n1sh_> I think the number is big <m4n1sh_> everyone wants to strike a balance between logging and privacy <thekorn> anyway, I'm off now. have a good night. and thanks for the discussion <RainCT> It'll be big once we have a GUI <RainCT> Good night thekorn :) <seiflotfy> thekorn, as i said the development of the blacklist api should be iterative inside the zeitgeist team <seiflotfy> and when we r done workign with it internally <seiflotfy> we define the requirments <seiflotfy> then reimplemnt it <m4n1sh_> thekorn: gn * RainCT goes back to doing homework :( <seiflotfy> we need at least 2 iterations of design and code <seiflotfy> hehehehe <m4n1sh_> seiflotfy: RainCT how you people did GAJ <m4n1sh_> internal iterations <seiflotfy> m4n1sh, hehehehe <seiflotfy> m4n1sh, gaj was willy nilly hacking <seiflotfy> ;) <RainCT> m4n1sh_: GAJ doesn't expose an API, it can change as much as it wants. <mhr3> m4n1sh_, but dataproviders might use different means to ensure privacy , not blacklist <m4n1sh_> RainCT: yeah, but this also wont appear in trunk unless it is stable <RainCT> But GAJ would have needed much more planning <thekorn> btw, someone should attach the log of this discussion to the bug * thekorn has quit (Quit: leaving) <RainCT> it's been rewritten way to many times for no real change (Zeitgeist was rewritten several times too but in the way the whole concept was redefined) <seiflotfy> RainCT, with each iteration we figured out what needs to be better what is meaningful etc <RainCT> but of course just hacking is more fun than planning :) <seiflotfy> RainCT, we can use both <seiflotfy> i think a real agile development process on the blacklist is a great idea <seiflotfy> and as mhr3 its not big yet <seiflotfy> so we can run on it as muhc as we want <seiflotfy> we define reqs, design implementation, code, test, and then start over again <seiflotfy> until we think we have all we need :)
-- Blacklist API sucks https://bugs.launchpad.net/bugs/612344 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Framework: Triaged Bug description: Guys, GetBlacklist and SetBlacklist (without any signals) for an asynchrounous-by-nature API? Come on! How about changing it to Get, Add, Remove and a changed signal? That way it'd be actually usable... _______________________________________________ Mailing list: https://launchpad.net/~zeitgeist Post to : [email protected] Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
