Re: [gentoo-soc] Re: Gentoo stats server/client,

[Joachim Bartosik]

Argh. I misspelled address... I should have been delved yesterday.

On Tue, Mar 24, 2009 at 06:00, Alec Warner <antarus@g.o> wrote:

>  > To solve this problem I'd use less comfortable for users solution: user
> wold
> > have to create an account using an email ( of course it wouldn't be
> stored,
> > I'd store some one-way injective function of it*) and click an emailed
> link.
> > There would be no need for password - to confirm his[her] actions [s]he
> > would just click an emailed link.
>
> I'm a bit concerned that if the function is one-way, how you will know
> where to send these email links.  Would the user have to input their
> email address when making changes, and you gather it from the POST/GET
> data?


Yes. I'd rather not store user emails so it will be impossible for curious
people to access them. I think it's one thing less to worry about.

After some thinking I believe my first idea ( when there is need for users
to confirm something they give us their emails, we send them email they
click link) has some advantages ( addresses are not even temporally stored,
users don't need to remember logins or passwords so there is no need to
worry about password recovery) but might be annoying for users ( especially
"premium users" who will have to do many actions at once or users who have
to wait longer then 5 minuets to receive authentication email(s)).

More comfortable for users would be to use their email addresses as logins.
Again there is no need to store addresses ( we get address/ password
combination on log in, check if it is proper and we no longer need it). If
users forget their passwords they give us their addresses and click some "I
forgot my password so please give me a new one" button we send them new
password/ link to set new password page/ whatever password recovery
information and again  we do not need to store it.

It's not very important for my idea so I don't mind changing my mind.

 > Each user ( email) would have a hosts** limit ( probably set in server
> > configuration) 2 or 3 by default ( enough for average user, not enough to
> > easily spoil data). After some time of inactivity host/ account would be
> > removed.
>
> Just make the host limit configurable and we can debate defaults
> later.  Certainly there should be a limit and there should be some way
> to request more machines; we don't want users to create lots of
> different accounts to contain their legitimate data.  Retiring
> inactive accounts is a good idea, +1
>

Making hosts limit configurable should be really easy ( it's important to
remember to make it configurable though ;).


>  FYI, I have a working python client for portage/pkgcore/paludis that
> collects this data and outputs some XML (that I was later going to
> POST to a RESTful interface..that I never wrote ;p)
>

I'd love to take a look at it - it could save some time

 REST is HTTP, and you could do it with HTML, but it would be ugly ;p


Users shouldn't look at it ( client would fetch it, grab important message
and show the message to them if necessary).



> this stuff sounds pretty standard, and I think if any prospective
> students have developed webapps before its probably not very time
> consuming.  I would prefer python over PHP for maintainability within
> gentoo, but if you feel most comfortable in PHP I'm not going to make
> you use a specific language provided the code is readable.


I didn't try python for writing web stuff so I don't know if very simple
thing can be done very simply ( knowing python I'd guess it's so but I know
that writing this using PHP  would be very simple so I wrote it). I'll try
it ( could you recommend what should I check out? (
"Pylons<http://pylonshq.com/>(0.9.7 Released 2009-02-23) a lightweight
Web framework emphasizing
flexibility and rapid development." ?)). I'd prefer to use python for that
because I think mixing languages can cause unnecessary problems.

 > Data gathering:
> > It'd take data provided by user communication module, decompress it,
> apply
> > deltas etc. to create all-the-information-available about current state
> of
> > hosts.
>
> Here I'm thinking a reporting API that generates datasets.  Someone
> else (or you) can later render the report with javascript or
> something.


As for [RESTful] server part of it I don't see a problem with that ( maybe
time... ). But I really hate java script. I'll think about it.


>  > Cleaner:
> > Run from time to time ( by cron, frequency adjusted to needs). Remove
> hosts
> > and users that do not send data ( to conserve space) etc.
>
> Probably a trivial add on feature provided we store last modification data.


Trivial add on feature but also an important one ( if old host data stays in
database forever it will eventually spoil statistics).


> > Achiever:
> > Run from time to time ( cron, as needed). Data gathering provides only
> > information about hosts *right now*. Achiever would generate statistics (
> > like package popularity ( % hosts that installed it)) and store them to
> make
> > historical data available ( storing all host states history would be
> > extremely excessive).
>
> I'll call this a stretch goal (eg we think about it but delay
> implementation until the dataset gets fairly large).


I think it is important to store historical data but you're right that there
will be no need for it until there is enough data to make history
interesting.

-- 
Joachim