Re: Queue Order Changing

From: Stefan Kaczmarek <stefan_at_thezonie.org>
Date: Sat, 7 Apr 2007 13:34:06 -0700

Okay, so I'm assuming that I'll get the "big 'ole thumbnail" from you
guys? ;)

Just let me know as things (like the search and the queue
modification) get implemented so that I can hook up to them.

I've currently gotten the queue to show the simultaneous application
transfers, with the % done, rate, time remaining, etc. Implemented a
simpler progress bar, though, because nutter's was nutty.

Now, I am running into an issue of heap space. Right now, the max sim
transfers I can have is 5, but when a buffer is written out to file
and a new one created, I get a heap space barf, and it crashes. (I
guess that would be 60MB of heap space.) I can't even run it with 6
sim transfers, because the heap issue comes up immediately.

Now, consulting my notes, it looks like we wanted to have the user be
able to run 1-15 transfers simultaneously. Now, is that what we still
want? If that is the case, then I am going to have to alter things to
bring down the buffer size to fit 15 transfers into the heap space. I
think that to do that, I'm going to have to have a buffer size of 3MB
instead of 10MB, which could affect the piece size, etc.

So let me know if 15 transfers is the top limit.

I also want to get the server-side stuff implemented where the
application registers itself with the system, and then the web page
can get the listening port for the local application, because right
now it's hard-coded. It's basically the GUID, listening port, and the
local IP for the registering, and then the web page would just get
the port back when it queries the server. (The server would look at
the remote and local ip address of the incoming connection to figure
out which listening port they need to connect to.)

We'll also need the ability to, when the app comes up and registers
with the server, that it is told which users were last associated
with it, so that it can start downloading their queue without having
to wait for the user to fire up the webpage and login. I figure the
GUID will have a list of user accounts associated with it.

- Z

On Apr 6, 2007, at 4:00 PM, Dylan Douglas wrote:

> Z-
>
> Yeah, you're right about it being not needed for the add, since it
> would
> only be going to the top of the queue.
>
> Forgot about the priority stuff for the viral stuff and all that.
> I'll
> have to add something regarding priority to the table. Something
> simple, just like regular and high priority.
>
> The way you are assuming to add stuff to the queue is what I'm
> thinking
> also. Some "add to queue" link that pushes it at the top of the
> queue.
> I would think that a regular (non-viral) add would add at normal
> priority, not the full speed super fast download priority that viral
> links get.
>
> The search doesn't work yet. I'm still trying to get the Ares sources
> and info data to come from the correct table, rather than the kluged
> together version that you are getting data from right now.
>
> As for the related stuff, I would think a combination of both. A big
> ol' thumbnail with a message that they haven't downloaded this
> yet... do
> ya want to queue it up?
>
> -D
>
>
>> -----Original Message-----
>> From: Stefan Kaczmarek [mailto:stefan_at_thezonie.org]
>> Sent: Friday, April 06, 2007 2:16 PM
>> To: Dylan Douglas
>> Cc: Ivan Kwok; Ben Ebert; Ty Heath; Jay Mairs
>> Subject: Re: Queue Order Changing
>>
>> D,
>>
>> Been getting good data, and the app can download from Ares now and
>> show status on web page, so woo hoo, it actually is possible! :)
>>
>> That's fine for the status (lock,unlock,add,delete,move) with
>> 'after=' being optional for the move, but I don't know why it'd be
>> used for the add.
>>
>> Like you said, stuff that is added is added to the top of the queue,
>> right? And then they can move it from there?
>>
>> So, I am assuming that the way stuff is added to the queue is them
>> clicking on a "add to queue" link that will be on the media page for
>> files? Like when they click the "related" links? I guess when we do
>> the search, the search results can have "add to queue" links too?
>> (BTW, Is the search implemented yet?) Or I guess if they click a
>> viral link it'll add stuff to the top of their queue.
>>
>> And when they add stuff to their queue, is it at the normal,
>> background priority? Or is it full-speed? I know we wanted viral link
>> downloads to be full speed, but what about non-viral link queue adds?
>>
>> Actually, here's something else I've been wondering: When they click
>> on a "related" link, or just something they haven't downloaded yet,
>> and it takes them to the media page, what are we going to show in
>> that window? Some sort of big-ole' thumbnail? Or just a "you haven't
>> downloaded this file" message?
>>
>> - Z
>>
>> On Apr 6, 2007, at 12:41 PM, Dylan Douglas wrote:
>>
>>> Z-
>>>
>>> Been working on this since yesterday. I think "add" and "delete"
>>> should
>>> probably be part of status, since hash would already be telling me
>>> what
>>> hash would be added or deleted. Having them as separate variables
>>> would
>>> just confuse things.
>>>
>>>> 1. account=<string>
>>>> 2. hash=<string>
>>>> 3. after=<string> - hash that the above hash is now after,
>> or not set
>>> if moved to the top of the queue
>>>> 4. status=<lock|unlock|add|delete|move>
>>>
>>> If 3 is optional for status:add and status:move. 3 won't be
>>> included
>>> for status:lock, status:unlock, or status:delete.
>>>
>>> If I remember right, the top 50 will be shown to the user and those
>>> are
>>> the ones that they can play with. So, if they found something they
>>> wanted to download, it would get added to the top of the queue. If
>>> they
>>> then wanted to move it down to queue position 25, that's their own
>>> doing. But, it wouldn't have any priority other than the queue
>>> position.
>>>
>>> -D
>>>
>>>> -----Original Message-----
>>>> From: Stefan Kaczmarek [mailto:stefan_at_thezonie.org]
>>>> Sent: Tuesday, April 03, 2007 6:11 PM
>>>> To: Dylan Douglas
>>>> Cc: Ivan Kwok; Ben Ebert; Ty Heath; Jay Mairs
>>>> Subject: Re: Queue Order Changing
>>>>
>>>> Ok, as per our super-cool chat, I've implemented the order changing
>>>> stuff, so I guess we can have a edit_queue.php (or modify_queue.php
>>>> or alter_queue.php or just queue.php if you want all the code in
>>>> one
>>>> file) that accepts the following variables:
>>>>
>>>> 1. account=<string>
>>>> 2. hash=<string>
>>>> 3. after=<string> - hash that the above hash is now after,
>> or not set
>>>> if moved to the top of the queue
>>>> 4. delete=<string> - hash to delete from the queue
>>>> 5. add=<string> - hash to add to the queue (are we going to allow
>>>> adds to the queue beyond the high priority downloads? Will those be
>>>> added to the queue, or kept separate? If they are added to
>> the queue,
>>>> then the priority of each item should be stored and sent down as
>>>> well)
>>>> 6. status=<lock/unlock> - or we can just have "lock" and
>>>> "unlock" be
>>>> things I just set, you know like "tivo.php?hash=123...def&lock"
>>>>
>>>> Let me know if you want to change this stuff, or if you
>> want to break
>>>> it up into separate files.
>>>>
>>>> - Z
>>>>
>>>> On Apr 3, 2007, at 4:04 PM, Dylan Douglas wrote:
>>>>
>>>>> Z-
>>>>>
>>>>> Yeah, once you tell me that hash X should be at position N, all
>>>>> the
>>>>> intermediate items between N_t0 and N_t1 will also change.
>>>>>
>>>>> E.g.: You have 10 through 17. The user moves 16 to 12.
>>>> The existing
>>>>> 12 through 15 are shifted up one to become 13 through 16.
>>>>>
>>>>> That's why I'm thinking of only dealing with a hash and
>>>>> position to
>>>>> prevent moving the wrong hash to the right position. You
>>>> just have to
>>>>> deal with the first request (move this hash there) and then the
>>>>> web
>>>>> service will take care of moving all the other stuff.
>>>>>
>>>>> -D
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Stefan Kaczmarek [mailto:stefan_at_thezonie.org]
>>>>>> Sent: Tuesday, April 03, 2007 1:14 PM
>>>>>> To: Ivan Kwok; Ben Ebert; Ty Heath; Jay Mairs; Dylan Douglas
>>>>>> Subject: Queue Order Changing
>>>>>>
>>>>>> D,
>>>>>>
>>>>>> So I'm working on the queue order stuff, and you said that
>>>> you wanted
>>>>>> to reference changes by the position in the db, not the webpage.
>>>>>>
>>>>>> So okay, what I have is a collection of objects in a
>>>> series, numbered
>>>>>> 0-n (the web page index) and each contain a db position that I
>>>>>> get
>>>>>> from the server.
>>>>>>
>>>>>> Now, when a user changes an item's position, I check the
>> web order,
>>>>>> and from there I can figure out which item moved from where,
>>>>>> and I
>>>>>> can tell you that "db pos item N moved to replace db pos item
>>>>>> M" ...
>>>>>> But I don't know how you're storing stuff in the db, so
>>>> does that now
>>>>>> update the item position values? So, does pos item N now
>> change its
>>>>>> position value to M? And do all of the items in between
>> shift their
>>>>>> position values as well?
>>>>>>
>>>>>> The collection maintains the original position values
>> (the web, 0-n
>>>>>> numbers) so I can track an item's movement during multiple
>>>> orderings.
>>>>>> (Until they refresh the page, of course.) I just don't
>> know if your
>>>>>> db position values are fixed or what.
>>>>>>
>>>>>> - Z
>>>>>>
>>>>
>>>>
>>
>>
Received on Fri Sep 14 2007 - 10:55:52 BST

This archive was generated by hypermail 2.2.0 : Sun Sep 16 2007 - 22:19:45 BST