On Sat, Jul 7, 2012 at 5:32 AM, Eliezer Croitoru <eliezer / ngtech.co.il> wrote:

> well this is the reason i am trying to:
> 1. make it more modular by using methods that can be changed easily
> 2. thing about efficiency.
> 3. consult with others.
>
> for now there is one guy that requested me for that ACL of deny\allow per
> ldap group policy.
> so my main goals now are:
> 1. fix bugs to make it bug free( i have some that i know of and might have
> others that i dont ).
> 2. add a more accurate url match filtering then just host\domain.
> 3. add user\ip db integration for future filtering\acl capabilities.
> 4. improve the filtering based on categories\level.
> 5. add a form that will allow a user to report a false-positive to the
> admin.
> 6. add a "user custom allowed\denied domains\urls list".
> 7. create a category option for the "custom allowed\denied domains\urls" so
> a user\admin can add to a user specific allowed categories.
> for the above option i must really think more before implementing the
> filtering acls as levels or categories etc..
> 8. content auditor module
> ( i had in mind to add an option of "content inspector\inspecting\auditing".
> what i mean is to add a feature that will log requests urls\domains\pages on
> a db so some human inspection on the content later can be done.
> so in environment like small isp\office that want to build his own
> blacklists\categories based on users browsing experience\habits the "content
> auditor" will get the list from the the DB somehow. )
> 9. live urls\domains access statistics on a DB for admins.
> (squid has logs but not live statistics)
>
> i had just one simple goal and it became more then just that and i'm happy
> for that.
>
> any ideas on the subjects?

There's probably so much that can be said to all of them but I am
lacking time.  My first impression was to proceed like this

1. write down all the _business_ requirements in a structured way (for
example, it seems to me that you want something like global and local
lists although I don't see that explicitly mentioned)
2. make a designing session to come up with an architecture
3. find out how you get from what you have to the new design / architecture

For example: for me it is not clear why you need a RDBMS in there if
you do not plan for large lists and plan to use its features.

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/