Comment 14 for bug 612344

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 (~ba@78.90.207.121) 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 :)