transfer::copy::queue(n)

💖 transfer::copy::queue(n) — the queued-transfers bestie 💖

okay so welcome to transfer::copy::queue, a page from the Tcllib manual set (that's the tcllib collection, transfer::copy::queue(n), version 0.2 — we'll get to the cute sign-off at the end, promise 🎀).

---

✨ NAME ✨

transfer::copy::queue — queued transfers. literally the whole vibe is "put your transfer requests in a line and let them take turns" 💅

---

✨ SYNOPSIS ✨

package require Tcl 8.5 9

package require snit ?1.0?

package require struct::queue ?1.4?

package require transfer::copy ?0.3?

package require transfer::copy::queue ?0.2?

transfer::copy::queue objectName outchannel ?options...?

objectName method ?arg arg ...?

objectName destroy

objectName busy

objectName pending

objectName put request

---

✨ DESCRIPTION ✨

so this package hands you objects that serialize transfer requests for one single channel using a fifo queue. that's it, that's the whole concept 🫶 accumulated requests get executed in order of entrance, and generally the first request that reaches an idle object is the one that kicks off execution. new requests can totally be added while the object is already active — they just get defered until every request that came in before them has been completed successfully. queue etiquette, honestly 👑

and now the sad part 😭 when a request causes a transfer error, execution stops and all the requests coming after it are not served. currently that means their completion callbacks are never triggered at all. not late. not with an error. never. 💀

NOTE: not triggering the completion callbacks of the unserved requests after an error stops the queue object is something the author is not fully sure makes sense. it forces the user of the queue to remember the callbacks as well and run them — because otherwise everything in the system that depends on getting a notification about the status of a request will just hang in the air 🫠. the author is slowly convincing himself that it is more sensible to trigger the relevant completion callbacks with an error message about the queue abort, and 0 bytes transfered. character development, honestly 🌈

all transfer requests look like this:

{type data options...}

where type is in {chan, string}, and data specifies the information to transfer. for chan, data is the handle of the channel containing the actual information to transfer. for string, data contains the information to transfer directly. the options are a list of them and their values, and they're the same ones accepted by the low-level copy operations of the package transfer::copy ✨

and here's a lil glow-up tip that's straight from the docs, no cap: just prepend the request with transfer::copy::do and insert a channel handle in between data and options, and it easily transforms from a pure data structure into a command whose evaluation will perform the request. it's giving glow-up montage 🦋

---

🌸 API 🌸

📦 PACKAGE COMMANDS

• transfer::copy::queue objectName outchannel ?options...? — this command creates a new queue object for the management of the channel outchannel, with an associated Tcl command whose name is objectName. that object command is explained in full detail in the sections Object command and Object methods. the set of supported options is explained in the section Options.

the object command will be created under the current namespace if objectName is not fully qualified, and in the specified namespace otherwise. the fully qualified name of the object command is returned as the result of the command 🎀

🧚 OBJECT COMMAND

all objects created by the ::transfer::copy::queue command have the following general form:

• objectName method ?arg arg ...? — the method method and its arg'uments determine the exact behavior of the command. see section Object methods for the detailed specifications 👑

💅 OBJECT METHODS

• objectName destroy — this method destroys the object. doing so while the object is busy will cause errors later on, when the currently executed request completes and tries to access the now missing data structures of the destroyed object. so like… don't 🙈
• objectName busy — this method returns a boolean value telling us if the object is currently serving a request (i.e. busy, value True), or not (i.e. idle, value False). vibe check on the queue, basically ✨
• objectName pending — this method returns the number of requests currently waiting in the queue for their execution. a request that's currently being served is not counted as waiting. fair 💖
• objectName put request — this method enters the transfer request into the object's queue of waiting requests. if the object is idle it will become busy and immediately service the request. otherwise, servicing the new request will be defered until all preceding requests have been served. get in line bestie, we're doing this in order 🫶

---

✨ OPTIONS ✨

the only option known is -on-status-change — that's it, one (1) option, she's an icon 👑

• -on-status-change — optional, and it defaults to the empty list, which disables the reporting of status changes. otherwise its argument is a command prefix which is invoked whenever the internal status of the object changed. the callback is invoked with two additional arguments, the result of the methods pending and busy, in this order. this lets any user easily know, for example, when the object has processed all outstanding requests 🔥

---

🌈 USE 🌈

a possible application of this package and class is within a HTTP 1.1 server, managing the results waiting for transfer to the client.

it should be noted that in this application the system also needs an additional data structure which keeps track of outstanding results, as they may come back in a different order than the requests from the client, and releases them to the actual queue in the proper order. so like, one extra lil organizer, no biggie 🧚

---

💀 BUGS, IDEAS, FEEDBACK 💀

this document, and the package it describes, will undoubtedly contain bugs and other problems (she said it, not me 😭). please report such in the category transfer of the Tcllib Trackers [http://core.tcl.tk/tcllib/reportlist]. please also report any ideas for enhancements you may have for either the package and/or the documentation. besties love a good bug report 🫶

when proposing code changes, please provide unified diffs, i.e. the output of diff -u.

note further that attachments are strongly preferred over inlined patches. attachments can be made by going to the Edit form of the ticket immediately after its creation, and then using the left-most button in the secondary navigation bar. it's giving very specific but very helpful instructions 💅

---

🔑 KEYWORDS 🔑

channel, copy, queue, transfer

---

👑 CATEGORY 👑

Transfer module

---

📜 COPYRIGHT 📜

Copyright (c) 2006 Andreas Kupries <andreas_kupries@users.sourceforge.net>

---

and that's the whole page bestie 🎀 this came out of tcllib, version 0.2, for the transfer::copy::queue(n) manual page — go forth and queue responsibly 💖✨🦋