Yep... Me too, ahm... but is this a pool?wahaha wrote:Well, that's what I'd vote for
REQ: Burning (state of the file) [Granted & Closed]
Moderator: AniDB
dunno,wahaha wrote:MULTIEDIT: To continue the original topic:
The last agreement was to choose one of these states, right?
* Watched/On-Hdd
* Watched/Burned
* Watched/Deleted
* Unwatched/On-Hdd
* Unwatched/Burned
i thought 3 states are enough.
unwatched
watched
watched+deleted
I mean if the user has those files on hdd or on cd doesn't make a real difference. And it's also no really usable information for the user himself.
BYe!
EXP
Maybe, if ppl really want to use AniDB to organize its anime collection, other classes (other than those on AniDB) could be available on the client...exp wrote:I mean if the user has those files on hdd or on cd doesn't make a real difference. And it's also no really usable information for the user himself.
No?
Juding by the color it is (uwaah, lame joke - I know ^^)nich wrote:Yep... Me too, ahm... but is this a pool?
But since there are less than 10 people atm who discuss the features, it's no problem to do polls that way
In fact you can easily abuse any of the free-text-fields like the already mentioned "storage"-field. Or - even more strange - add extended data in an .ini-liek way to the "desc"-field.exp wrote:on the client?
u mean they should be stored on the local hdd and only be displayed in the anidb client?
About the "burned"-state of files:
It'd be useful to have a quick overview if you think of fulfilling a ReShareRequest or providing a patch for a (hopefully to come) request-method.
!file x -> "on cd" -> "/msg ... nah, maybe tomorrow"
!file x -> "on hdd" -> "/msg ... wait a sec, I'll look where I left that file"
There should - as always
- be an easy way to access this option in IRC. Maybe "!burned animeX y-z"("!unburned" then too, I wonder... ^^)
hm,
dunno, actually the storage field was ment to be used for stuff like that.
the big question is, is there any gain for the AniDB if it can tell if a user has the file on hdd?
but i guess we'll need more than those 3 stats anyway. i.e. stuff like
"release" (meaning this user is releasing/actively power sharing that file)
"shared" (this user is sharing that file)
"onreq" (this user is willing to share the file on short notice)
"default" (std. setting, this user might be notified about reshare requests)
"noshare" (this user is unwilling or unable to share that file, reshare requests will never be forwarded to this user)
hm, that'd probably be a completely different file stat field.
in addition to the "unwatched" "watched" "watched/deleted" entries.
although "watched/deleted" might automatically select the file as "noshare" too.
BYe!
EXP
dunno, actually the storage field was ment to be used for stuff like that.
the big question is, is there any gain for the AniDB if it can tell if a user has the file on hdd?
but i guess we'll need more than those 3 stats anyway. i.e. stuff like
"release" (meaning this user is releasing/actively power sharing that file)
"shared" (this user is sharing that file)
"onreq" (this user is willing to share the file on short notice)
"default" (std. setting, this user might be notified about reshare requests)
"noshare" (this user is unwilling or unable to share that file, reshare requests will never be forwarded to this user)
hm, that'd probably be a completely different file stat field.
in addition to the "unwatched" "watched" "watched/deleted" entries.
although "watched/deleted" might automatically select the file as "noshare" too.
BYe!
EXP
Hm..exp wrote: on the client?
u mean they should be stored on the local hdd and only be displayed in the anidb client?
yeah... if it has information useful only for anime collection management, why should anidb have it? store it on local HD...
But if it shows itself useful, like for fast resharing request, etc, then it should be part of AniDB system.
well,
if it is only needed on the client the request belongs into the anidb client feature request forum
maybe individual categories might be a nice feat there, but IMHO the anidb cgi doesn't need them.
however the shared status information would of course only be usefull if it is part of the anidb.
BYe!
EXP
if it is only needed on the client the request belongs into the anidb client feature request forum
maybe individual categories might be a nice feat there, but IMHO the anidb cgi doesn't need them.
however the shared status information would of course only be usefull if it is part of the anidb.
BYe!
EXP
(Reshare)Request-feature would still be great.
It could work like this:
A user who wants to request a file will have to add it to his mylist. there he sets the state to 'request'.
If a user requests a file all other users who have got the file not shared can see in their mylist a little icon/mark next to the anime title (and when expanding the tree next to the file).
The request is canceled either if the requesting user changes the file-state from 'request' or after a certain timeout (1 week for example) or after x people have changed their filestate to 'release' for that file.
Multiselecting would be nice (as it works with the other states as well).
Hope this helps you exp when implementing this (I think it shoud be possible with some more sql-statements for the check if there is a request and just adding one state to the filestate-combo.
It could work like this:
A user who wants to request a file will have to add it to his mylist. there he sets the state to 'request'.
If a user requests a file all other users who have got the file not shared can see in their mylist a little icon/mark next to the anime title (and when expanding the tree next to the file).
The request is canceled either if the requesting user changes the file-state from 'request' or after a certain timeout (1 week for example) or after x people have changed their filestate to 'release' for that file.
Multiselecting would be nice (as it works with the other states as well).
Hope this helps you exp when implementing this (I think it shoud be possible with some more sql-statements for the check if there is a request and just adding one state to the filestate-combo.
Sounds like a good strategy...
On top of that, with a whole list of reshare requests it is possible to distribute these over groups of users who have these files. That way not your whole list is coloured requested but a subset.
F.E. I am looking for Brain Powerd. I do a request. Say 100 people requested other series and 10000 people have files. then only say 20 get the request for BP, and not all who have it in favor of other requests.
As user, i'd expect a reshare request list in the myplace area and not really in the mylist. Mylist i use to organise the collection and more funcionality on top of that would clutter the interface.
The reshare list can also be used to collect the 'ok, i'v got it' type of messages if the request is cancelled by the issuer on completion.
Colours can be like:
-- red: request (reshare request count > 0)
-- green: reshared
-- yellow: revoked/cancelled/ok (reshare request count == 0)
I guess that such idea is only possible independant from the animelist. Maybe you only need the Anime-ID, Episode-ID's (when opening the anime) and the extra status.
On top of that, with a whole list of reshare requests it is possible to distribute these over groups of users who have these files. That way not your whole list is coloured requested but a subset.
F.E. I am looking for Brain Powerd. I do a request. Say 100 people requested other series and 10000 people have files. then only say 20 get the request for BP, and not all who have it in favor of other requests.
As user, i'd expect a reshare request list in the myplace area and not really in the mylist. Mylist i use to organise the collection and more funcionality on top of that would clutter the interface.
The reshare list can also be used to collect the 'ok, i'v got it' type of messages if the request is cancelled by the issuer on completion.
Colours can be like:
-- red: request (reshare request count > 0)
-- green: reshared
-- yellow: revoked/cancelled/ok (reshare request count == 0)
I guess that such idea is only possible independant from the animelist. Maybe you only need the Anime-ID, Episode-ID's (when opening the anime) and the extra status.
I think it would be neat, if it was implemented right here because:
1. Sometimes there is just one chunk missing and as anidb knows the file it can easily find users who have this file complete. (I guess you do not know the ed2k-link of every file you put on cd, do you?)
2. Less 'spamming' in Animereactor-forum.
3. No need to look for RSRs in the long list of threads, as they will find you.
4. Less work for all people involved.
5. Even lazy people (who don't read AR-forum) might reshare something.
That's what I think.
@alaureijs: I think the distribution would be nice, but it would be an overkill for the sql-statements.
1. Sometimes there is just one chunk missing and as anidb knows the file it can easily find users who have this file complete. (I guess you do not know the ed2k-link of every file you put on cd, do you?)
2. Less 'spamming' in Animereactor-forum.
3. No need to look for RSRs in the long list of threads, as they will find you.
4. Less work for all people involved.
5. Even lazy people (who don't read AR-forum) might reshare something.
That's what I think.
@alaureijs: I think the distribution would be nice, but it would be an overkill for the sql-statements.