Supporting named configs/file groupings in the API

[lcwill]

In adding support for configs on the client-side, you'll be able to arbitrarily group the directories that will be tracked by the daemon and name these groupings. I envision the config file looking something like this:

user.id=lwilliams123
code.tracking.group=Maestro Dev
/usr/local/adnxs/m3api
/usr/local/adnxs/m3ui
/usr/local/adnxs/m3scripts
/usr/local/adnxs/schemas/maestro
code.tracking.group=Personal Projects
/home/lwilliams/git-repos
code.tracking.group=All Dev
/usr/local/adnxs/m3api
/usr/local/adnxs/m3ui
/usr/local/adnxs/m3scripts
/usr/local/adnxs/schemas/maestro
/home/lwilliams/git-repos

The UI could then display these as 3 separate sections (or maybe tabs) in the coding timesheet. In order for that to work, we'll need to add some extra information to each curl request, I'm thinking in the query string:

64.208.137.22:3000/save-event/lwilliams123/1327967595?groups=All%20Dev,Maestro%20Dev

This way, a timestamp could be associated with multiple groups. How does this sound?

[jhuttner]

I think a few things to decide on here. YAML or JSON. I vote for YAML only because I use JSON all day at work.

I think the event should be sent via POST. So just send to /save-event and then pass key/value array: second, groups.

More generally...

Is the above better than having one daemon running for each unique user id?

How will the UI know that lwilliams and lwilliams-private are related to each other? The app has no concept of a relationship between timesheets, as it exists today.

[lcwill]

I'm all for using YAML, and also agree that we should be sending the events via POST. Now, about the UIDs, I was actually trying to make a distinction between a user ID and a "category" or "group" ID.

My proposal is that each user have a single, unique ID which can be specified in their config file, or it will default to the login ID. The user will also be able to define one or more groupings which will consist of: an ID, a display name (optional), and a list of directories. Each file event will be a POST containing the user ID, timestamp, and a list of ID/name pairs identifying the groups to which the particular file belongs (a file/directory could potentially belong to more than one group).

The API would need to maintain a mapping of user IDs to the set of group IDs that it has seen for that particular user. This approach has the advantage of allowing you to view all of your groupings in a single timesheet - or maybe have multiple timesheets that are accessible from a single URL. I'd also prefer not to use separate daemons since this increases the complexity and it probably wouldn't scale as well as having a single process.