[06:52] zubov: yeah should be good to start that. Though is there any chance of refactoring that branch into just org.drftpd first? would make things simpler to find and would seem like a good opportunity to do it [07:30] <-- OpEn-FiRe has quit (Ping timeout: no data for 255 seconds) [07:35] --> OpEn-FiRe (~open@201.72.97.64) has joined #drftpd-devel [07:37] <-- OpEn-FiRe has quit (Client Quit) [07:38] --> OpEn-FiRe (~open@201.72.97.64) has joined #drftpd-devel [07:38] <-- OpEn-FiRe has quit (Client Quit) [07:38] --> OpEn-FiRe (~open@201.72.97.64) has joined #drftpd-devel [07:48] <-- OpEn-FiRe has quit () [07:48] --> OpEn-FiRe (open@201.72.97.64) has joined #drftpd-devel [09:18] ugh rewriting the control channel stuff as a plugin looks nasty :) [09:37] hey [09:41] hi [09:42] gonna refactor [09:42] net.sf.drftpd [09:42] to org.drftp [09:42] to org.drftpd [09:42] nice [09:42] I keep looking in the wrong one for classes ;) [09:48] grgrg [09:53] some packages conflicts [09:55] --> Kalidarn (~X@219-90-229-133.ip.adam.com.au) has joined #drftpd-devel [09:55] hi. [09:55] i asked about a formal RFC spec for PRET a while ago [09:56] if drftpd's method is to take off in many clients i think its important they document and submit a proper RFC spec [09:56] a developer i am working with will only impliment protocols such as FXP etc that have these specifications [09:56] PRET the way i see it is an extension of the FTP protocol [09:57] http://www.drftpd.org/index.php/Distributed_PASV [09:57] http://filezilla.sourceforge.net/forum/viewtopic.php?t=3288&highlight=&sid=3054b31ea33ad942f990962a34b24fbc [09:58] http://www.drftpd.org/index.php/PRET_Specifications [09:58] same thing Michel [09:58] oh, i didn't read, just pasted [09:58] :) [09:59] we were looking for formal specs similar to RFC or IETF [09:59] there was one [09:59] somewhere [09:59] ah okay [09:59] http://www.nesc.ac.uk/talks/ggf5_hpdc11/GridFTP_protocol220702.pdf ? [09:59] The PRET command on that page has a different syntax than the one in the paper. [09:59] http://www.drftpd.org/index.php/Distributed_PASV#Solution:_PRET_.28PRE_Transfer.29_command [09:59] no [09:59] mog__ wrote that [10:00] right [10:00] so which one is the best one to use [10:00] i mean the one we are talking about and is implemented in drftpd [10:00] right [10:00] mog__ was the one that started the PRET thing and even coded a patch for pftp [10:00] http://www.drftpd.org/index.php/PRET_Specifications = dead [10:00] http://www.drftpd.org/index.php/Distributed_PASV#Solution:_PRET_.28PRE_Transfer.29_command = dead [10:01] they work fine [10:01] grr i can't even get to http://www.drftpd.org/ [10:01] must be a DNS issue [10:02] mog__ prolly has the proper documentation [10:03] if you can hold here and wait for his reply [10:03] ah okay [10:03] good :) [10:03] because when i get this to the developer [10:03] he's the one that wrote the so called RFC [10:03] they will impliment this feature [10:03] it's not hard to implement [10:04] yeah but he is just a bit anal about making sure there is a RFC or officials standard [10:04] like the other protcols [10:04] ie a formal draft [10:04] http://filezilla.sourceforge.net/forum/viewtopic.php?t=3288&highlight=&sid=3054b31ea33ad942f990962a34b24fbc [10:04] check the thread [10:05] there is no formal draft [10:06] ya [10:06] well could one be written? [10:06] Michel i think there is [10:06] RFC and/or IETF? [10:06] well at least i thought [10:06] mog__ wrote one [10:07] when might m0g be back? [10:07] *mog [10:08] the gridftp PRET and drftpd PRET are different things btw [10:08] ah [10:08] how different? [10:08] do they effectivly do the same thing? [10:08] no [10:08] ah okay [10:08] quote from the wiki [10:08] GridFTPD [10:08] GridFTPD defines ERET, ESTO and more for sending of striped files. It doesn't help distributed transfers however. [10:09] right [10:10] he says " about http://www.drftpd.org/index.php/Distributed_PASV#FEAT_response_for_PRET, there is this command: "PRET RETR [ignored arguments]" . Where the filename ends and the ignored arguments start the syntax of this command is ambiguous, thus he won't implement it. [10:12] Michel, so your saying DRftp's command PRET and GridFTPds command PRET are both PRET but they do different things? [10:12] depending on which daemon theyre used on? [10:13] dunno [10:13] if this is the case we suggest to design a new command with formal specs that isn't used for anything yet, since PRET seems to have two different implementations [10:14] when a formal spec is written it reserves this from occuring [10:14] i have never seen a client that implements gridftpd's pret [10:15] true [10:15] yeah the point is PRET is PRET [10:15] you can't have two PRETS [10:15] its like having the word "The" mean two different things. [10:15] the point is it's a pretty substantial thing although it may not seem like it [10:16] your effectivly extending FTP with this command [10:16] and hence it needs to be documented so the standard is known [10:19] the 2 major windows clients (flashfxp and ftprush) use drftpd's PRET [10:19] Kftpgrabber too [10:20] Kde ftp client [10:20] lftp [10:20] yeas im aware of this [10:21] simply stealing the code can't work though [10:21] stealing code? :) [10:21] well borowing [10:21] ie to understand it [10:21] as it's client code, it doesn't necessarily represent the full syntax and semantic [10:22] the link i pasted, has a pretty decent description of PRET [10:22] right [10:25] just wait for mog_, mayb he has an RFC type spec [10:25] mm [10:25] because he says: [10:25] here's one HUGE flaw with the link you gave me [10:26] in it, there's "PRET RETR [ignored arguments]" where does the filename end and the ignored arguments start? it's ambigious [10:26] ambigous where? [10:26] file comes first [10:26] dot [10:26] ops [10:27] [ignored arguments] just means a client should ignore any other arguments [10:27] i guess [10:27] yeah [10:27] kangaroo [10:27] ops [10:27] Kalidarn [10:27] isn't ambiguous at all [10:27] client should read everything after RETR as filename [10:27] that will be helpful too http://trac.drftpd.org/ticket/113 [10:27] look at this: PRET RETR long filename with spaces [10:28] then the ftpd will read "long filename with spaces" as the filename [10:28] --> codesquid (~codesquid@kong.kawo1.RWTH-Aachen.DE) has joined #drftpd-devel [10:29] enjoy ;) [10:29] hi [10:29] [ignored arguments] shouldn't even be there [10:29] yeah [10:29] but it is, that makes the description inconsistent [10:29] does RETR accept any argument at all in the RFC [10:29] ofc, no othe rway [10:29] *no other way to tell it the filename [10:30] RETR [10:30] codesquid [10:30] --- yoda sets modes [#drftpd-devel +l 60] [10:30] read that http://trac.drftpd.org/ticket/113 [10:30] mm drftpd.org still dead for my DNS [10:31] what's the IP to the site? [10:31] nslookup it [10:31] my DNSes aren't able to reach it [10:31] 217.118.222.1 [10:31] IP won't work [10:31] put it in your hosts [10:31] =( [10:33] mm that didn't help :P [10:34] can you please write up some formal, consistent specs for PRET, in a style similar to an RFC or IETF draft/spec? So I can archive it on my site for future reference [10:37] ill elinks it from SSH :D [10:38] m that works ;) [10:39] codesquid [10:39] thing is, PRET does not need any parameter but the filename [10:40] then document it [10:40] this was kinda discussed here [10:40] hammer it in stone [10:40] http://trac.drftpd.org/ticket/113 [10:40] that's no specification [10:40] for example here in drftpd we use PRET to warn master about an upcoming transfer and master will lookup in which slave that file is and make the slave ready for transfer [10:40] when you issue STOR/RETR [10:41] you can have parameters or whatever you want [10:41] since that is there where all the real work happens [10:41] checkings [10:41] etc... [10:43] PRET simply must be issue before any data connection of any type happens [10:44] PRET STOR/RETR/LIST/NLST/MLST/... [10:45] http://www.drftpd.org/index.php/PRET_Specifications#PRE_Transfer_Command_for_Distributed_PASV_Transfers [10:46] changing the subject [10:46] Dom im only missing net.sf.drftpd.master.command.plugins [10:46] I'm sorry but that's inconsistent [10:46] dunno where to refactor that shit [10:47] codesquid ok it can be inconsistent [10:47] but that's all we have I guess [10:47] all i can assure is that most clients follows *our* implementation of PRET [10:48] but if there are two FTPds using PRET for different things [10:48] fr0w: doubt that bit matters too much since they should be replaced anyway [10:48] doesn't that cause an issue [10:48] if you can understand how it works and could write a simple draft, that would be a great for the whole community [10:48] wouldn't that be best written by someone who wrote the command? [10:49] i can't, i don't even know the "right way to do it" [10:49] are you one of the main coders that coded the command though? [10:49] that will best [10:49] not sure if he wants or have time to [10:49] he's not much involved w/ the project currently [10:49] well personally i think as your project is licensed under GPL [10:49] but still do somethings when avaiable [10:50] it should be done [10:50] Dom sure thing, they will eventually be replaced or refactored again [10:52] just playing with moving the ftp control channel out into a plugin but is slow going [10:52] since it is very tightly integrated [10:53] atm I have a org.drftpd.master.Master instead of ConnectionManager , that does the general startup stuff and then has an extension point of "CommandHandler" where it finds extensions and starts them [10:53] then got a StandardFTPHandler plugin that hooks into that and does the rest of what ConnectionManager did, ie set up a listen socket and spawn connections [10:54] well it doesn't actually do that yet, gets about as far as the listen socket ;) [10:56] mhmmh [10:56] i dont get it [10:57] guess you are taking that too low level [10:57] the FTP/IRC [10:57] was simply releated to the actual command handlers [10:57] cuz we were having multiples copies of the same function [10:58] well the idea was taken from `tds suggestion [10:58] to abstract the method of receiving input too [10:59] so people can add on anything they want as a way to communicate with the ftp [10:59] but the way you doing it [10:59] we are ending w/ a VirtualFileSystem [10:59] that can handle irc/ftp/http [10:59] yeah I guess so [11:00] by no means saying I'll actually bother doing this bit, was just something to play with really and see how it worked [11:00] the idea is to create a way to receive inputs 'on the highest level' [11:00] highest level goes for real user input [11:01] like a !nuke or 'site nuke' [11:01] ;) [11:01] yeah I know [11:01] what MUST be changed is the CommandHandler [11:02] sure that is going to be changed [11:02] so we can use a single method to execute an action from httpd/ftpd/irc [11:02] so i can manage my userdb [11:03] thru a webinterface for example [11:03] Dom when your jpf basic is finished [11:04] i will implement my mysql usermanager [11:04] and do a svn diff [11:04] basically my thoughts were something like this, some.interface.for.input<->command.manager.of.some.sort<->separate.command.plugins [11:04] you still using Blobs? [11:04] nope [11:04] not more [11:04] varchar, int, decimal, boolean [11:04] the middle bit being so that the input interface doesn't have to deal with registering lots of commands or anything like that [11:05] i can publish my mysql structure before. if you like to see it.... [11:05] yeah do it [11:05] when you can [11:05] i'd like to have a look at it [11:05] what will me a good place to do so? [11:05] `tds- would like too [11:05] xinu [11:05] be* [11:05] ticket [11:05] ? [11:06] do we already have one? [11:06] nope [11:06] create [11:06] okey dokey [11:06] Dom your thoughts are right but you are trying to do it a on low level basis [11:06] one of the reasons I was playing with moving out all the ftp control chans was to see if it was possible to not treat ftp interface as a special case [11:06] making a DrFTPd/HTTPd/FOOLD [11:06] lol [11:07] because if it weren't a special case then technically any command would be available to any interface including file transfers etc, though agreed that really isn't needed [11:07] yeah that isnt [11:08] i will export 2 users 2 [11:08] data still a job for the ftpd [11:08] its just to visualize [11:08] we are not planning to make it bigger than that [11:08] afaik [11:10] looks like it'd be too much work to do anyway tbh ;) [11:10] read carefully http://www.drftpd.org/index.php/CommandHandler_restructure/tds and http://www.drftpd.org/index.php/CommandHandler_restructure/fr0w [11:11] read them [11:11] tds even draw some grapichs [11:11] that graphics shows 100% what we need [11:11] i was even thinking about trying to give this commandhandler a shoot [11:11] but that would be duplicate effort [11:12] maybe you could write your own wiki page about what you think [11:12] so that we can look [11:12] and finally merge into a final solution [11:12] or we are going to get anywhere [11:12] most of it is basically merged from those 2 [11:13] so try to write the merged version [11:13] as we didn't [11:14] though `tds has written his (probably unintentionally) so it implies what I was just playing with [11:15] ie by saying stuff like listen ips/ports are properties of the ftp interface [11:15] well [11:15] i dont think he wanted to say that [11:15] not sure [11:15] he's very creative [11:15] when really the ftp interface would just be sitting on top of all the underlying stuff and just handling commands sent over the control channel [11:15] rather than handling the control channel itself [11:15] whata big mess huh [11:15] now im confused [11:16] zubov `tds- show up [11:16] help is needed [11:16] :P [11:16] lol [11:16] im going to go take a photo of the sky [11:16] gotta jet for a few [11:16] ttyl [11:17] though I think doing that would be too much work to start with even if it was wanted, huge amounts of stuff hook into ConnectionManager and BaseFTPConnection [11:17] which in that model would have to be handled by a plugin for the ftp interface [11:17] so would need to rework everything that used them [11:17] ok cya [11:18] too cloudy =( [11:19] mmm [11:19] new clamav updates [11:19] commiting the net.sf.drftpd clean up [11:19] wonder how that will look [11:20] 13 Feb 02:50:29 ntpdate[19571]: step time server 207.188.193.108 offset -2.598776 sec [11:20] my clock was out of date [11:23] <-- codesquid has quit (Read error: Connection reset by peer) [11:24] <-- Kalidarn has quit (Quit: Kalidarn) [11:24] --- yoda sets modes [#drftpd-devel +l 58] [11:24] done [11:25] gotta jet now [11:25] cya [11:25] cya [11:25] http://trac.drftpd.org/ticket/155 [11:26] was just reading that [11:26] need to abstract out the current usermanager to a plugin at some point, then can easily switch to alternate ones like that [11:35] xinu: btw if you do integrate that as a plugin you should consider doing it as 2 [11:36] because of?! [11:36] actually nevermind, will all be JDBC so can just provide a .conf entry or something for the sql backend they want [11:37] i currently have all configs in my drftpd.conf [11:42] --> Kalidarn (~X@219-90-229-133.ip.adam.com.au) has joined #drftpd-devel [13:47] <`tds-> I'm not going to read the entire scroll, waaay to much right now, but if you're still stuck on naming the "ftp frontend" (your words) why not just make it a Frontend instead of an interface ? : [13:47] <`tds-> zubov `tds- show up <-- what ? [13:48] hehe [13:48] was talking about [13:48] [17:11:28] read carefully http://www.drftpd.org/index.php/CommandHandler_restructure/tds and http://www.drftpd.org/index.php/CommandHandler_restructure/fr0w [13:48] <`tds-> xinu if u post something big in a ticket, please use an attachment! [13:49] i did [13:49] <`tds-> I didn't look, just saw it in the scroll and panic'd.. thx :d [13:49] lol [13:49] i just had to write some more sentecenes to be hopefully clear for everyone [13:49] you know my english... [13:49] :-/ [13:56] <`tds-> <+fr0w> so we can use a single method to execute an action from httpd/ftpd/irc <-- this is of course essential.. the problem is how will an addon create a new button/menu in your web frontend, or enable a new command in the ftp frontend or irc frontend etc.. w/o knowing in advance what frontends exist.. seems impossible. So let's assume that either the siteop has to manually setup the commands (like now in commandhandlers.conf for example) which sucks imho, [13:56] <`tds-> hope that didnt' get cut off [13:58] sucks imho, [13:58] was the last part :D [13:58] <`tds-> which sucks imho, or that a plugin author can support frontends that could potentially exist, but don't necessarily have to on every site. [14:00] <`tds-> and with jpf we are not limited in that we can not support pre/post hooks, I don't imagine, but is there any less or more of a need for them now with jpf ? [14:11] <-- Michel has quit (Ping timeout: 248 seconds) [14:11] --> Michel (blaze@2001:618:400::5511:131c) has joined #drftpd-devel [14:15] --> iKm (iKm@adsl-ull-125-96.49-151.net24.it) has joined #drftpd-devel [14:15] hi all [14:16] --- yoda sets modes [#drftpd-devel +l 60] [14:28] hi iKm [14:42] tds [14:42] it is a simpli fix [14:42] but the last drftp+ trunk can't compile [14:43] <`tds-> hmm whatd i screw up [14:43] public class PortRangeTest extends TestCase { [14:43] <`tds-> oh [14:43] PortRange pr = new PortRange(45300, 45310); [14:43] <`tds-> I thought I added ,0 in there ? [14:43] no [14:43] eheh [14:44] <`tds-> hmm [14:44] <`tds-> I added it in one of the test classes, lol. [14:44] <`tds-> the main stable didn't have it tho [14:44] <`tds-> i don't think [14:44] baa np just to know [14:45] <`tds-> fixed, anything else before i commit ? [14:46] only this [14:46] i have just downloaded :P [14:47] <`tds-> hmm.. ok it seems looking thru the commit history that I never comitted the fix, and i don't have it in my local copy.. so odd.. I coul dhave sworn i did it [15:24] <-- mog_ has quit (Ping timeout: 202 seconds) [15:24] --> mog_ (~mog@81-236-1-77-no61.tbcn.telia.com) has joined #drftpd-devel [16:15] --- yoda sets modes [#drftpd-devel +o `tds-] [16:16] --- `tds- sets modes [#drftpd-devel +vvvv Dark`-` Dom iKm Michel] [16:16] --- `tds- sets modes [#drftpd-devel +vvv mog_ xinu zubov] [16:16] --- `tds- sets modes [#drftpd-devel -o+v `tds- `tds-] [16:17] yeah i got voice [16:17] now i can talk whatever i want to :D [16:17] <`tds-> woo hoo [16:17] lol [16:18] <`tds-> now you can let loose [16:18] damn i dont know what "let loose" means [16:18] omg [16:19] ah [16:19] ok [16:19] <`tds-> http://dictionary.reference.com/search?q=let+loose&r=66 [16:19] * Nozz slaps tds [16:19] :D [16:20] 10. sexually promiscuous or immoral; unchaste. [16:20] lol [16:20] <`tds-> well I didn't mean go streaking or anything :D [16:20] a. to free or become free. [16:20] am i free now? [16:20] :D [16:23] <`tds-> and I meant by streaking :: http://dictionary.reference.com/search?q=streaking&r=66 [16:23] <`tds-> #4 under v. intr. [16:23] <`tds-> I believe that means instransative verb [16:24] oh man [16:24] to many foreign words at this time for me [16:25] im going to bed [16:25] <`tds-> hehe [16:25] <`tds-> nn [16:25] nn [16:29] someone have a home server? [16:29] <`tds-> i have, why ? [16:30] wich cpu? [16:30] i want to assemble a home server [16:31] <`tds-> oh [16:31] <`tds-> I'm just using an old workstation atm, converted into a linux server for dev/testing various projects [16:32] <`tds-> what do you need to do with it ? [16:32] drftpd master [16:32] <`tds-> but for testing? or [16:32] mysql [16:32] not for testing [16:32] for real [16:32] :\ [16:32] <`tds-> production then, hmm [16:33] <`tds-> i dunno :D if u are using 2.0 then depends how many clients/slaves it will have [16:33] like 15 [16:33] slaves [16:33] and 50 users [16:33] <`tds-> AMD Athlon(tm) 64 Processor 3200+ is what I'm using with no users and 1 slave with hardly any files, and it's fine hehe.. [16:35] <`tds-> hmm.. unmodded 2.0 u can probably get by on a p43Ghz equivilent dual core, like a pentium d or something, to start, then upgrade to something better when it starts to bog down.. [16:35] <`tds-> that way you don' thave to invest a ton into it at first just to get it going [16:35] <`tds-> 1g of ram to start, and expect to work up to 2 if u have lots of small files. [16:35] <`tds-> or even 4 [16:36] <`tds-> depends on your situation [16:36] i belive you can manages with alot less then 4gb ram [16:36] <`tds-> 2.1 hopefully fixes all of these problems, but we can't tell w/o throwing 15 slaves and a tone of files/users at it to see :D [16:36] hey [16:36] did i miss something? [16:36] <`tds-> Nozz, if he's got 15 slaves worth of small files on it, maybe not [16:36] <`tds-> hey fr0w, been looking for u [16:37] my bro closed mirc i guess, or it crashed, just got home [16:37] <`tds-> i only see u on efnet [16:37] how mutch bw you think master need for 15 slave and 50 users (normal ftp usage) [16:37] <`tds-> hehe [16:37] iKm nothing, it barely uses bw [16:37] 100gb [16:37] <`tds-> ikm, I've never measured it [16:37] and you will never reach it [16:37] <`tds-> i think he means kb/sec fr0w [16:37] yes [16:37] kb/sec [16:37] oh [16:38] i was looking on ebay at an opteron server [16:38] opteron 144 [16:39] <`tds-> yeah i'm using a dual core opteron 275 in production [16:39] <`tds-> but with more slaves, and more users [16:40] <`tds-> not actually using it yet, migrating to it, whenever i get around to that [16:40] * fr0w *shrugs* [16:40] <`tds-> haha [16:40] * `tds- exhales [16:44] `tds- are you messing w/ the trac box? [16:45] <`tds-> i was yesterday have not been on today, what's wrong ? [16:45] welp seems to me that it isnt getting updated [16:45] i commited something 6 hours ago [16:45] and it isnt there [16:46] <`tds-> hmm [16:46] <`tds-> ok I'll check [16:48] <`tds-> cron didn't run it due to some bad permisisons, i guess i screwed them up [16:49] i bet [16:49] <`tds-> haha thx :D [16:50] <`tds-> updated by hand for now [16:50] <`tds-> i think the perms are fixed remind me to check logs again in 20 minutes [16:50] k [16:52] `tds- [16:52] did you read the convo i read w/ Dom? [16:52] earilier today? [16:53] <`tds-> some of it [16:53] <`tds-> btw, i think zubov's last commit said he was going to try and make a commit to enable us to track file history etc, your refactor might make that more difficult for him :D [16:54] nope [16:54] file history was kept [16:55] all files that were moved [16:55] are marked as Copied from: ... [17:04] are foxconn motherboard good? [17:06] sweet fr0w [17:07] yah, tds, i did mention that, but I didn't start it yet, so no harm :) [17:08] ;) [17:08] guess what i did kept the history, right? [17:08] if you scroll, zubov, read what i spoke to Dom earlier today [17:08] yah, i'm catching up :) [17:09] plis tell me if i missed something, cuz last thing i read was me saying 'gotta jet' like a 5~6 hours ago [17:19] not really [17:19] tds didn't add much :) [17:19] one thing he did add was... [17:20] <`tds-> <+fr0w> so we can use a single method to execute an action from httpd/ftpd/irc <-- this is of course essential.. the problem is how will an addon create a new button/menu in your web frontend, or enable a new command in the ftp frontend or irc frontend etc.. w/o knowing in advance what frontends exist.. seems impossible. [17:20] So let's assume that either the siteop has to manually setup the commands (like now in commandhandlers.conf for example) which sucks imho, or that a plugin author can support frontends that could potentially exist, but don't necessarily have to on every site. [17:20] <`tds-> and with jpf we are not limited in that we can not support pre/post hooks, I don't imagine, but is there any less or more of a need for them now with jpf ? [17:21] i think it's a very good point [17:22] the first part, not sure about the pre/post hooks, from what Dom was saying, I think we can implement them as extension points of whatever commandhandler (if the commandhandler allows it) [17:22] kalidarn: we're not writing an IETF/RFC spec for PRET [17:22] kalidarn: honest answer is, we don't care about it enough to write one [17:23] kalidarn: there are already bunches of ftp clients that implement OUR version of PRET without any problems with the spec we provided [17:25] i agree w/ that pre/post hook comment [17:25] i guess extension points makes it all easy [17:25]