View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000637 | LDMud 3.5 | Efuns | public | 2009-05-18 12:16 | 2009-06-03 16:06 |
| Reporter | zesstra | Assigned To | zesstra | ||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Target Version | 3.5.0 | Fixed in Version | 3.5.0 | ||
| Summary | 0000637: RfC: Remove the efun cat() | ||||
| Description | In the discussion about 0000636 on -d-code, there was a suggestion to remove the efun cat(). cat() is nearly the same as read_file()+tell_object() - the biggest difference being that cat() does not read in the whole file. Please comment on this idea. | ||||
| Tags | No tags attached. | ||||
|
|
Ah, BTW: For a removal I would suggest the following strategy: deprecate the efun now in 3.3.x and remove it in 3.5.1, because I don't like to remove it from one minor release to the other. I had a quick look in our mudlib and it is used about 110 times, so we have to introduce a sefun as replacement in MG. I guess, it is a good idea to start our reference simul_efun.c which contains suggestions for sefuns emulating removed efuns (I think, we discussed the in some other bug shortly). |
|
|
I agree. |
|
|
I once thought cat() could be the superhighway for files on the disk to be copied to a socket bypassing the main LPC memory.. like throwing an mp3, an xvid, an flv or mp4 directly at an httpd or socket of other protocol. |
|
|
Mhm, that would be a different semantic compared to the current one. You could think of mmapping a file to some memory page(s), directly use that as buffer and transfer it. Possible, and reportedly faster then lseek()+read(). Using sendfile() may be another approach, but I don't know, if sendfile() is POSIX and widely supported. But in both cases, it is very different to the current cat(), which transfers a range of lines, not the complete file or a range of bytes. So probably it would be better to use a differently named efun() (e.g. sendfile()) for this. How often do you transfer (large) files directly without any pre-processing? |
|
|
We do have situations where swfs, applets, javascripts and graphics need to come from the same host as the http application, and I increasingly like to implement web applications on top of psyced because of its decentralized multi-user awareness. But if ldmud/psyced were a rock solid httpd, I would probably kick out Apache, migrate all websites... saving one IP address and simplifying my general web technology configuration. I have some DJ mixes for download etc, so files can enter the hundreds of megs range. Then again, I might be a borderline case. Other thoughts go into direction of doing file sharing or pubsub apps using the userbase.. throwing MP3s at PSYC sockets in order to have them distributed to all subscribers in realtime.. sendfile(2) allows for using incoming TCP sockets instead of files as the source, which is interesting, too. So I guess you are right, cat() is a candidate for simul_efun. sendfile() or something like it is the thing. |
|
|
Heheh .. wait... the LPC tradition is to have implicit sockets tied to objects.. therefore, sendfile(inobject, outobject...) is too much like socket libs. cat() already uses the implicit output socket being this_interactive(), now if the source can be an interactive object instead of string - poof, you are copying data from that interactive's socket to this interactive's socket without even changing the lpc API much. |
|
|
You are certainly a borderline case. ;-) At least compared to all muds, which don't really transfer large files as raw data. And additionally, I think some sendfile() on the telnet socket will break something. ;-) So, it is something which can only be used on other (TCP) sockets. I guess, if somebody wants to work on it, I don't object, by I personally would probably do other things first. I looked up sendfile() and found out, that it is not standardized in any way and its use in portable programs is discouraged. That suggests using mmap() to me for implementing sendfile(). |
|
|
You are changing the _semantics_ and the API of cat() significantly. cat() counts _lines_ in textfiles (which don't really exist in random files) and transfers the desired range of lines. What you suggest can not attempt to count lines if its purpose is to efficiently transfer (large) binary files, you can either transfer a complete file or a range [byte_x...byte_y]. And using an object as source for cat() instead of a string describing the location of a file is also a major change in API, although that can be alleviated a bit by using 'mixed'. And then cat has to raise a privilege violation, because you can't allow random objects to copy raw data from the socket of one interactive to the socket of another interactive. |
|
|
Uh oh.. always neglecting some details like the *lines* feature of cat() which would require some #define CAT_USE_BYTES flag to make sense for binary files. Ok, let's send the cat() to simul-efun-wonderland and think of sendfile() elsewhere... |
|
|
I'm for removing cat() as well. Here's a possible sefun replacement (depending on the mudlib it may require some efun:: prefixes): #define CAT_MAX_LINES 50 varargs int cat(string file, int start, int num) { if (extern_call()) set_this_object(previous_object()); int more; if (num < 0) return 0; if (!start || !this_player()) start = 1; if (!num || num > CAT_MAX_LINES) { num = CAT_MAX_LINES; more = strlen(read_file(file, start+num, 1)); } string txt = read_file(file, start, num); if (!txt) return 0; tell_object(this_player(), txt); if (more) tell_object(this_player(), "*****TRUNCATED****\n"); return strlen(txt & "\n"); } Where do we want to put compatibility sefuns? How about ${TOP}/mudlib/deprecated/cat.c for this one? |
|
|
Sorry, the ' || !this_player()' condition belongs to the previous if. (It was an afterthought, and I pasted it to the wrong location.) |
|
|
Ok, then it is decided. I will take care of this soon. ${TOP}/mudlib/deprecated/ sounds good to me. Additionally, we might include a ${TOP}/mudlib/deprecated/simul_efun.c which #includes all the single files (each coding one removed efun as sefun) in that directory. |
|
|
efun marked as deprecated in r2593. I move this bug to 3.5 and set the target version to 3.5.1 for removal. I will add the sefun Fuchur suggested later today or tomorrow. |
|
|
cat() was removed in r2627. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-05-18 12:16 | zesstra | New Issue | |
| 2009-05-18 12:16 | zesstra | Status | new => assigned |
| 2009-05-18 12:16 | zesstra | Assigned To | => zesstra |
| 2009-05-18 12:16 | zesstra | Status | assigned => feedback |
| 2009-05-19 02:31 | zesstra | Note Added: 0001116 | |
| 2009-05-19 02:33 | Gnomi | Note Added: 0001117 | |
| 2009-05-22 02:00 | lynx | Note Added: 0001132 | |
| 2009-05-22 04:19 | zesstra | Note Added: 0001138 | |
| 2009-05-22 05:01 | lynx | Note Added: 0001140 | |
| 2009-05-22 05:05 | lynx | Note Added: 0001141 | |
| 2009-05-22 05:05 | lynx | Note Edited: 0001141 | |
| 2009-05-22 05:14 | zesstra | Note Added: 0001142 | |
| 2009-05-22 05:23 | zesstra | Note Added: 0001143 | |
| 2009-05-22 05:37 | lynx | Note Added: 0001144 | |
| 2009-05-23 16:07 | fufu | Note Added: 0001148 | |
| 2009-05-23 16:08 | fufu | Note Added: 0001149 | |
| 2009-05-25 07:54 | zesstra | Relationship added | related to 0000636 |
| 2009-05-25 07:59 | zesstra | Note Added: 0001152 | |
| 2009-05-25 07:59 | zesstra | Status | feedback => assigned |
| 2009-05-26 05:53 | zesstra | Note Added: 0001161 | |
| 2009-05-26 05:53 | zesstra | Project | LDMud 3.3 => LDMud 3.5 |
| 2009-05-26 05:54 | zesstra | Product Version | 3.3.718 => |
| 2009-05-26 05:54 | zesstra | Target Version | 3.3.719 => 3.5.0 |
| 2009-06-03 16:06 | zesstra | Note Added: 0001192 | |
| 2009-06-03 16:06 | zesstra | Status | assigned => resolved |
| 2009-06-03 16:06 | zesstra | Fixed in Version | => 3.5.0 |
| 2009-06-03 16:06 | zesstra | Resolution | open => fixed |
| 2009-09-30 13:56 | zesstra | Relationship added | related to 0000228 |
