Documentation for FXP.One API commands and protocol. This documentation file is maintained at
http://www.lundman.net/wiki/index.php?title=Protocol and exported to other formats. This documentation is purposly maintained rigorously as to aid all client developers of FXP.One.
We have been thinking about buying our own place for a while, just wasn't sure where. It could be when we move back to New Zealand, or, perhaps some other country (a few offers have popped up), and maybe Tokyo itself. We have lived in an apartment in Tokyo for about 13 years, and that has been great. But it would be nice if it was *ours*.
I have been keeping an eye out on the realestate search pages, just to see what is available. We were looking for something around 4LDK, so that the boys can have separate rooms. A stand-alone house would of course be very nice, but also checked a few apartments and mansions. (Japanese mansions are not mansions!)
== Connecting ==
In March 2015 we asked to see a couple of houses, one in particular stood out to us. I had seen it on the market for a while (over a year at least), it has 131m^2 land, and 220m^s inside, so you know it is expensive! Quite a bit outside our budget, maybe if it was half price! It was full of furniture and garbage, apparently the previous owner had not managed to keep up with the payments, and the bank foreclosed the house. But that is an interesting thing, almost all places we looked at to buy, were "not clean". "Would it have killed you guys to at least vacuum?". Talking about the places that were empty. It seems the Japanese always "remodel" after they move in, so cleaning isn't paramount?
One interesting thing that popped up when discussing the financials of the very expensive property, is that they mentioned the realtors fee, and the fee to the bank, and then "you will need to give a couple of million gift to the previous owner". Wait, what? Clearly I feel for the previous owner, but that is peculiar? I, the buyer, have to give a gift of money, to the guy who could not pay his mortgage and it was foreclosed? Clearly, I know nothing about realestate.
=== WELCOME ===
It is also common for the realestate staff to want to pick us up in a car, to take us to the property, even if it is just in our area. I understand that the "customer is king" is important, and so that is part of the service. But sometimes, it was much more convenient for us to cycle over to the property. I also found I enjoyed the challenge of finding the Internet listed properties in an area, by just going on the images and other clues. Good way to get out in the weekends. We were quite lucky that the realtor had someone who spoke in English, this was a great benefit to our understanding.
When you connect to the FXP.One server, you should receive a greeting
string, similar to:
After seeing a (incredibly cluttered) house, which apparently had to pay a fine every month for being over-sized (so you can purposely build too big and just pay a little more?), the realtor popped in to show a bit of land on the way back home...
Pay special attention to the SSL flag here, since if it is enforced,
and you attempt plain text authentication (which will fail) you are
exposing the user and password.
We had not really thought about looking at land at all, so initially I was not really looking seriously at it. But it had some interesting potential. Off the main road, still near the Odakyu line (as we are already used to), in the same area so the school does not change for the kids. Corner lot. Had the typical blue tarp covering it, of course, this is Japan after all. 87m^2 land for ~60M yen. This is shibuya-ku so, yeah, expensive.
The "version" is the server version and build
The "protocol" is the protocol version, which you can check to be of
the same Major type as your application knows.
[[File:land.jpg|thumb|Land]]
The "SSL" field can be "disabled", "optional", and "forced".
One thing that is interesting is the new rule about having a 4m access road to new houses. (For emergency vehicles). Since the road to this lot (or rather, the house that used to stand there) does not, there is a 2m "setback" on the land where you are not allowed to build. You own the land, but can't place any permanent buildings on the part which is for the 4m access road. So, it feels like you are buying 68m^2 for ~60M yen.
But not really. In Japan, the land comes with two percentages. With this land, those values are 60% and 300%. This means that you can build (foot print) on 60% of your land area, which is from the original 87m^2. Ie, about ~54m^2 can occupy the land area. Which is smaller than the 68m^2 (setback included). So it is more about *where* on the land you can place your building, in our case, toward the west corner (bottom left on the image). This leaves the setback area for parking our bikes and similar.
=== SSL ===
The second number, 300%, is the total size you are allowed to build. Ie, when adding floors. As it happens, 3 floors at about 54m^2 is only about half that, so that has not yet been an issue. There is also a sunlight rule, but I'll bring that up later.
Initiate SSL challenge. This is sent by clients requesting the
remainder of the session to be in SSL. This requires that FXP.One
engine's WELCOME message is either "forced" or "optional".
When talking financials with the realtor, they explained that if I got an average mortgage for the 60M yen land, the monthly payment would be about 16man yen. (160,000) But, while there is no house on the land, you can pay just the interest on the mortgage, about 4.6man a month. Until the day you move in. You get a second "part" to the mortgage that pays for the house building, and start paying the full amount once you move in. So the system is not completely against you, if you consider buying land and building a home.
At one point we took some sticks, to make a 5m long pole, put a camera at the end of it to get a 360 of the view from 3F. A drone would have been easier, maybe.
[ Minimal Required Fields]
Very much a roller-coaster ride this whole adventure, some days we are all for-buying, and others days against. A fair bit of stress involved, and you are quite aware that the easiest thing to do, is to do nothing. (not buy)
[ Optional Arguments ]
=== Design ===
[ Returns ]
>> CODE=<int> - Command return status CODE.
>> OK - Initiation request accepted, start SSL phase.
>> MSG - Human-readable message string
[ Example ]
<< SSL
>> SSL|CODE=0|Msg=Attempting SSL negotiations.
=== AUTH ===
Send USER and PASS for authentication. This requires a valid user and
password pair already registered on FXP.One. If FXP.One was started
with no user database files, it will create one with the account user
"admin" and password "admin".
[ Minimal Required Fields]
>> USER=<str> - USER name
>> PASS=<str> - PASSWORD
[ Optional Arguments ]
[ Returns ]
>> CODE=<int> - Failure code.
>> MSG=<str> - Human readable string message.
[ Example ]
<< AUTH|USER=admin|PASS=admin
>> AUTH|CODE=0|MSG=Successful
>> AUTH|CODE=502|MSG=Login incorrect
>> AUTH|CODE=503|MSG=Secure channel enforced.
== SITES ==
For SITE structure definition, see [[Site_Definition]]
It is recommended that all clients that wish to store information
in the site database, to prefix their key values with a unique string,
perhaps the name of the application. For example:
lundfxp_sitecmd_1=SITE WHO
lundfxp_lastlogin=015368281
=== SITELIST ===
Lists all defined sites.
[ Minimal Required Fields]
[ Optional Arguments ]
>> SHORT - Send only short list (siteid + name)
>> SITEID=<int> - Send only specified siteid. Sends no BEGIN/END keys.
[ Returns ]
>> SITEID=<int> - Site ID being displayed.
>> NAME=<str> - Name of site. Not used by engine, need not be unique.
>> HOST=<str> - Hostname of remote FTP server
>> USER=<str> - User name for authentication on remote FTP server
>> PASS=<str> - and password
>> PORT=<int> - Optional PORT of remote FTP server. [1]
>> PASSIVE=<yna> - Use passive for directory listings? [See YNA type]
>> FXP_PASSIVE=yna - Can this remote FTP only take PASV, or PORT?
>> CONTROL_TLS=yna - Attempt SSL/TLS on Control channel?
>> DATA_TLS=<yna> - Attempt SSL/TLS on Data channel? Site needs CCSN feat
>> IFACE=<ip> - Optional IP to bind() to. [1]
>> IPORT=<int> - Optional PORT to bind() to. [1]
>> DESIRED_TYPE=yna- Binary or Ascii mode transfers. [1]
>> RESUME=<yna> - Attempt to Resume before Overwrite. [1]
>> RESUME_LAST=yna - Re-queue items needed resume last in the queue. [1]
>> PRET=<yna> - Send the extended Pre-Transfer command before transfer[1]
>> FSKIPLIST=<str> - File skip list [1]
>> DSKIPLIST=<str> - Directory skip list [1]
>> FPASSLIST=<str> - File pass list [1]
>> DPASSLIST=<str> - Directory pass list [1]
>> FSKIPEMPTY=<yna>- Skip empty files [1]
>> DSKIPEMPTY=<yna>- Skip empty directories [1]
>> FMOVEFIRST=<str>- Pattern file matches to force queue at top [1]
>> DMOVEFIRST=<str>- Pattern directory matches to force queue at top [1]
>> BEGIN - First item sent, start of list.
>> END - Final item was sent, end of list.
[1] This information is only sent if the current value differs from
the default "AUTO" type. Or, in the case of strings, where the string
is defined (not-empty).
[ Example ]
<< SITELIST|BEGIN
>> SITELIST|SITEID=2|NAME=localhost|HOST=127.0.0.1|PORT=21|USER=mp3|PASS=mp3|PASSIVE=1|FXP_PASSIVE=2|CONTROL_TLS=2|DATA_TLS=2|optional_variable=roger moore
>> SITELIST|SITEID=2|NAME=localhost|HOST=127.0.0.1|PORT=21|USER=mp3|PASS=mp3|PASSIVE=1|FXP_PASSIVE=2|CONTROL_TLS=2|DATA_TLS=2|optional_variable=roger moore
=== SITEMOD ===
Modify an existing site's key/value pairs. Specify as many items as
desired to be changed. Items not specified in the command are left as
they are. To delete a key/pair, send the key with an empty value
field. For example "key=".
[ Minimal required fields ]
>> SITEID=<int> - Site ID of created site.
[ Optional Arguments ]
>> NAME=<str> - Name of site. Not used by engine, need not be unique.
>> HOST=<str> - Hostname of remote FTP server
>> USER=<str> - User name for authentication on remote FTP server
>> PASS=<str> - and password
>> PORT=<int> - Optional PORT of remote FTP server. Default 21.
>> IFACE=<ip> - Optional IP to bind() to.
>> IPORT=<int> - Optional PORT to bind() to.
>> DESIRED_TYPE=yna- Binary or Ascii mode transfers. [See YNA type]
- AUTO and engine will set Binary for transfers.
>> RESUME=<yna> - Attempt to Resume before Overwrite.
>> RESUME_LAST=yna - Re-queue items needed resume last in the queue.
>> PRET=<yna> - Send the extended Pre-Transfer command before transfer[1]
>> FSKIPLIST=<str> - File skip list [2]
>> DSKIPLIST=<str> - Directory skip list [2]
>> FPASSLIST=<str> - File pass list [3]
>> DPASSLIST=<str> - Directory pass list [3]
>> FSKIPEMPTY=<yna>- Skip empty files
>> DSKIPEMPTY=<yna>- Skip empty directories
>> FMOVEFIRST=<str>- Pattern file matches to force queue at top
>> DMOVEFIRST=<str>- Pattern directory matches to force queue at top
[1] AUTO means it will use this feature if it is reported by the
remote FTPD in the FEAT/features command reply.
[2] Uses fnmatch(3) syntax pattern matching. Most file globbal you can
do on the command line, including "*?[]", but excluding "{}". String
consists of slash separated patterns. eg "*.dat/*readme.txt*".
[3] Opposite to skiplist. The default is for passlist to be empty,
which is the equivalent of "*". A syntax like "*ENGLISH*" would ensure
only entries which matched string would be queued, and others are
dropped. Uses same pattern syntax as skiplist.
[ Extended Optional Arguments ]
As a special feature to the clients connecting to the FXP.One engine,
we also allow for storing of own, arbitrary, key/value pairs. As long
as the "key" is not the same as any of the above keys, or that of the
It is recommended that all clients that wish to store information
in the site database, to prefix their key values with a unique string,
perhaps the name of the application. For example:
lundfxp_sitecmd_1=SITE WHO
lundfxp_lastlogin=015368281
=== SITEDEL ===
Delete an existing site.
[ Minimal required fields ]
>> SITEID=<int> - Site ID of created site.
I looked around for a way to design a house, and there are many tools on the Internet. Some for browsers, some free apps, others to buy etc. But the foreign tools did not really work out. It became clear that I needed to use a Japanese made design program, to get the "standard" sizes of things, like the set bathrooms, stairs, genkan, and all that. Clearly there is a monopoly going on here, as it seems there is just one software, and it was quite expensive (for my hobby level interests). So I went a bit more oldskool, and started measuring things at home to get an idea of how much space are needed. Typical Japanese apartment bath/shower room seems to fit in 2m x 2m, and so on.
[ Optional Arguments ]
Eventually, I sent a sketch to the realtor that I had made of what I thought could work on the land we were looking at. Features 2 bedrooms, bath/shower, toilet on 1F, 3 bedrooms and toilet on 2F, the LDK on 3F with small balcony, and rooftop balcony above that.
[ Extended Optional Arguments ]
[[File:mydesign1.jpg|thumb|My first design]]
[ Returns ]
>> SITEID=<int> - Site ID of created site.
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message.
A couple of days later I received a proper (Japanese style) floorplan based on my initial sketch. Some interesting differences showed up. I figured that the top floor (3F in our case) would be the LDK area, ie, any "awake hours" we would spend here, so it should have the better "view" and sunlight. Since the bedrooms are generally only for sleeping, it would seem a waste to have those on the top floor. This doesn't appear to be the mindset here, both designer companies initially put the LDK in the middle, and bedrooms at the top. Perhaps there is a reason for it which we will learn one day...
[ Example ]
>> SITEDEL|SITEID=12
<< SITEDEL|CODE=0|MSG=Site deleted.
Anyway, we arranged a meeting with the first design company. We had no idea what to expect of course. So the realtor is not really connected with the house design, and eventual, building of the house. The realtors just assist with connecting us with those companies, so we can hash out ideas. It was quite interesting and productive. We could explain the reason behind some of our ideas, and they could explain why certain things could not be done. Usually load-bearing walls required, but also, emergency access - like that of the 3F balcony - has to have room for access.
[ Caveat ]
Sites aren't actually deleted, just not saved to disk. This means
active sessions using said siteid created before the SITEDEL command
was issued will continue to work.
They also showed that the rooftop balcony was "too tall", and that 3F had to be made narrower. We just assumed we had reached some height limit, and could not have a rooftop balcony.
It was actually a few days later that we finally had it explained to us. There is a sunlight rule in Japan, were you draw a line from the centre of the road(s), at some angle I have yet to learn, up into the sky. Everyone using the road(s) are entitled to sunlight. This is why the North and East side of the house (since the roads are North and East) has to have angled roofs, and "come back" in a little in the design. I had placed the rooftop balcony stairs in the east corner which is the worst place for it. Had the stairs been on the South, or West sides, there would have been no issues.
We got a quick estimate at about 20M to build the house, going up to 25M including all the extras, insurance, realtor fees, and stamps. Interestingly, you have to pay a few man yen for a stamp for the land, stamp for the house, stamp for registering the land, stamp for registering the house. Just think of it as lots of small taxes.
== SESSIONS ==
After this, we also met with (one of?) the biggest house builders in Japan, and they showed us their design, and floorplan. Quite different to to my initial sketch, but also some neat ideas. They too placed LDK in 2F, but had no issues moving it to 3F. They had rooftop balcony already, so this is where we learnt it was possible to have one. We had a chance to visit friends, who very recently bought land, and built a house - very similar to what we had in mind. Got lots of measurements out of it, so we could better "see" what our designs would be like. Also to practise climbing 2m x 2m stairs. We really loved their rooftop balcony, which is why we started thinking that we want one too.
A session refer to a site connection. The API will ask for a new
session to a specific site (specified with SITEID) and a session will
be created. If the connection is lost or closed, _the session is
closed_. The API will have to request a new session if so desired.
The second design was estimated at closer to 30M, but their pricing is based on the building area. In our case, 120m^2. So we can change anything inside and the price is the same. In Japan list the "penthouse" separately, as well as rooftop balcony as extras and are not counted towards the 300% limit. The penthouse is the "stairs and door" part that opens to the rooftop balcony.
=== SESSIONNEW ===
Both (rough) house estimates, they made sure to say "before discounts". Unsure what sort of discounts we are talking about here, if it's just a few man, or something serious.
Request a new session to site, returning a SID to session.
It took at least 2 meetings with the first designer before they reluctantly suggested that having the kitchen in the low-ceiling area is probably not the best. Seriously, I'm here for your advice, just tell it to me straight.
[ Minimal Required Fields]
>> SITEID=<int> - Which remote server to connect to, from SITELIST.
We sent back revisions to both companies, for the different floorplans. Apparently, the floorplans and companies have to be kept separate, no sharing between them.
[ Optional Arguments ]
>> LOG=1 - Normal login is silent. With LOG the API received
all verbose messages.
=== Mortgage ===
[ Returns ]
>> SID=<int> - Value of the new SID for all future commands with
sessions
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message.
We filled in the paper work for 2 of the bigger banks in Japan, it is more of a pre-application to see if they want to talk to you, and what sort of numbers we could get. There is no commitment yet. They insisted that I write my name (katakana) and address (kanji) by myself, by hand. I softly suggested that they could write the address and I just do my personal details and sign (hanko) it. That was a big nono, had to be me, writing my address. Took forever, but got there eventually. Luckily, I had practised writing my address when I applied for my Permanent Residency.
[ Example ]
>> sessionnew|siteid=0
<< SESSIONNEW|SITEID=0|SID=1
<< IDLE|SID=1
4 days later we get the news that neither bank wanted to help with a mortgage. With no reason given. I got the impression that if the banks were not happy with me, or my situation, they would give reason(s). But in this case, it seemed to be about the seller, or something external. Then the banks can not give reason(s). (liability?) At least, that was the gist of my understanding of the situation. The realtor may simply have been sparing my feelings. Who knows, we filled in another set of mortgage application forms (again, I had to write) and fired those off.
=== SESSIONFREE ===
This time it went better, in that we got an offer, and lots of numbers, and stats with it.
Release a session, and disconnect from remote host.
The next step was to fill in the "purchase approval" for the land, and hanko it. This is not binding either, we can decide not to buy it without any penalty. At this point they want a 3M yen down-payment, which we get back if the mortgage fails to come through, or we decline to purchase. It has a deadline a month in the future. The realtor is now negotiating with the seller of the land, and dealing with the bank.
[ Minimal Required Fields]
>> SID=<int> - SID of the session to close.
=== Land inspection ===
[ Optional Arguments ]
[ Returns ]
>> SID=<int> - SID of the session closed.
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message.
The realtor asked to meet us at the land today, they said it would be easier to explain in person. We went and found the land markers for the spot, and was surprised just how far into the road "our" land would be. It was explained that only the North side has a setback of about 30cm. The East side is not to do with the emergency access, but rather an agreement made with all the neighbours on the street. This was done before it was put on the market, and is part of the purchase contract. They wanted us aware of that. There is also a slight issue with the South-West corner house. Apparently it is built right on the edge of the land, so the roof, drain and drain pipe is "over sized". This means we have to have a survey made, and possibly shift our plans, and/or change the floor plan to accommodate it. I find it rather peculiar that is becomes the problem of the new buyers, and not the oversized house.
[ Example ]
>> SESSIONFREE|SID=1
<< SESSIONFREE|CODE=0|SID=1|MSG=Success
We received revised floorplan designs today as well, we have indicated we were interested in a shower stall on 2F and weren't sure if those could be done in Japan (since it is always shower/bath units). But that seemed to have been no issue.
=== ASYNC ===
I was asked if I take any medicine, or have some kind of health issue. This stems from that with a bank mortgage, you will get health insurance with it automatically. Japan is still lagging a little with gender equality, but in this case, if I happen to die, the mortgage is written off, as the wife "doesn't have any income". So that is all...uhh "good". I guess? Wait
Is not a command but client need to be aware that there are messages that
come in at any time.
=== Hanko ===
<< CONNECT|SID=1
Send once a session has successfully logged in and is ready to answer
queries. Initially it was thought that IDLE would be enough, but
clients will generally want to auto-trigger some commands upon
connection establish, so we provide this event.
We met with the builders again. Just to talk about some changes, and they had a few questions for us. Our bathroom was slightly non-standard size (+15cm) and that would cost extra. They asked if we would be happy with the bath standard unit size. We already live in a Japanese apartment which has the standard unit size, so that is fine by us. We also learnt that we do not fully know what options there are out there. For example, the balcony doors. At our current apartment, the balcony doors are glass, and one slides behind the other. So the biggest you can ever make it, is 50% open. Either the left side is open, or the right side. The we saw a model house with a folding glass door. Folded up like a "W" and since it "sticks out" when opened, you can have close to 90% of the door completely open. So we wanted that, talked to the builders about it and hashed out a plan. Then during the same meeting, we saw another model house, which featured balcony doors where one door hides behind the other, and both slide open. Leaving a complete 100% open way. Now we wanted this door instead. Clearly we need to know what is out there, but that is why we are going to model houses I suppose.
<< IDLE|SID=1
Site is idle, ready for more commands. Informative only as you can
always issue commands, they will be queued.
As for the day we sign off on the land, I need to have "Identification of certification of a seal impression", for my hanko. For this I had to go to Shibuya cityhall to apply. It is a card (like credit card size) with my hanko registration on it. I want to the cityhall, guessed the application form and filled it in. Once my number was up, I was told that before I can apply for "Identification", I have to actually have my hanko registered. So a slightly different queue. I made my hanko many years ago when I first opened my bank account. At the time, I felt Hiragana looked nicer than Katakana. Today I found out that I could not register my hanko, because it is in Hiragana. Off to Tokyu Hands, and had a new hanko made, this time in Katakana. Then back to the cityhall, get the new one registered, then apply for Identification, and receive my hanko ID card.
The session was disconnected. Any further references to the SID (in
this case "1") will result in an error.
In addition to this, I need resident card (including certificate from cityhall listing all people in my household). Record of withholding (tax) for 2 years. That other tax form thing, and proof of funds. (Our deposit funds, bank printout).
<< LOG|SID=1|MSG=
I was told it is normal to just bring cash, in normal bank envelope. One million yen is apparently 1cm thick. So 3 million will be about 3 cm thick.
You can request a SESSIONNEW to be logged (LOG), or, most of the
commands take an option "LOG" to specify that logging is desired
during the execution of said command. This means the engine will
forward all messages from the remote FTPD to the client. For example:
We had another meeting with the house builders, they explained the 3F balcony doors need to have outside roller shutters installed. We don't have to use them but they have to be there. They don't cost us any extra so that is no big deal. When we asked what they were for, the translation comes out as "Quasi Fire Hazard". So uh what. Clearly something to do with fire prevention, but only the balcony doors on 3F. Not the windows, not 1F ground level doors. It sounded like if a neighbours house was on fire, you can close the shutters, but who knows.
In preparation of the land purchase, we are preparing for the down payment, and mortgage loan meetings. Now we know what 3 million yen in cash looks like and apparently nobody bats an eye withdrawing that from the bank. I have been practising my kanji as well, since I have to write all my details in Japanese.
=== Purchase ===
== FTP COMMANDS ==
We met at the realtor's office to go through the purchase. Started at 14:00 and at first, it is the reading of the contract. The reader introduced himself and showed his ID to confirm he is qualified to read the contract to us. We had both a Japanese version as well as a version translated into English. Done in typical Japanese fashion, he reads the item number then the whole clause, out loud. One at a time. At anytime that the contract referred to anything, we were shown, and given a copy, of the official document. Started with the seller's company, then we were shown the official company registry, from the seller's cityhall. Complete with official stamps. When talking about the borders, we were shown both the 1970 geographical map, as well as the 2005 version. Followed by official Shibuya-ku water pipe maps, sewage pipes, tsunami flood area map and so on. Everything official, and stamped. Also talked about the special points about the property. That the neighbour's house is too close to our land, the setback for 4m road, the agreement with the neighbourhood that the road that leads to their houses will be left as a road. We were taught were the rubbish goes, and which owner is the community leader. The rubbish area needs to be cleaned every week and that is on a roster for the neighbourhood.
=== DIRLIST ===
We were shown the map of the work we need to do for the water pipe, it is just from in front of the neighbour, not from the main road. The contract also listed that there are old, not used, pipes under the land. All very detailed.
Request a directory listing from remote server/session.
After that, the representative for the seller showed up, and we could work on filling out the contracts. Mostly name, and address, leaving the hanko work to last which you do at the same time. You also hanko the backside of the contract booklet, over the spine - presumably to prevent tampering. Once that was done, we handed over the 3 million yen downpayment, in the envelope. The seller counted it, and then handed us a receipt (also hankoed and with an official post stamp). All paperwork, maps, contracts, photos showing the border-posts, was all filed into a dossier which was handed to us. Bowing and thanking the seller, that part was done.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
There was a large section about OCG activity and how that was illegal. Took us a while before we worked out it meant Organised Criminal Group, ie, the yakuza and those sort of activities. We skipped over most of it, cos, I guess, they felt we were probably not connected to the "OCG".
[ Optional Arguments ]
// Optional: PATH, ARGS, RAW, CACHEOK, LOG
>> PATH=<str> - Additional path element [1]
>> ARGS=<str> - Additional list options [2]
>> RAW=<int> - Include entire list line in FID reply.(unparsed)
>> CACHEOK - If cache is populated, avoid remote server
>> LOG - Send all strings with dirlist, like SESSIONNEW
[[File:dossier.jpg|thumb|The Dossier]]
[1] Warning. It is not recommended that you use this to supply
different paths as the internal cache engine will get mighty confused.
[2] Some "ls"/LIST options will break the internal parser. For
example, "-1" would remove the long listing style.
We had a short 5 minute break, then the representative of the Bank arrived, and we could start on the mortgage paperwork. Since the preliminary had been filled out, it was relatively straight forward. Just going over the numbers and the various options for the type of loan we preferred. This also included the life insurance. The everything-is-paid-off-if-I-die is included for free, but there were optional extras. For example, option 1 included a list of 50 different kinds of cancers, should I get sick and be unable to work, the loan is payed off. Option 2 was for heart attack, or stroke, same deal, or option 3 which included all. The difference was maybe 5,000 yen a month or so. So you can guess what will get you, and pick that option I guess. The best outlook is to get cancer and then recover, and you have no more mortgage. Not sure that is worth having cancer though.
[ Returns ]
>> SID=<int> - SID the dirlist reply is from.
>> FID=<int> - File ID of this item. For QADD.
>> NAME=<str> - Name of Directory OR File
>> DATE=<time> - FID's date/time stamp. In seconds since 1970.
>> SIZE=<int> - Size of Directory OR File
>> USER=<str> - Owner of entry
>> GROUP=<str> - Group of entry
>> PERM=<str> - Permissions string. TODO - add octal as well.
>> FTYPE=<str> - Type. "Directory", "File".
>> ITEMS=<int> - Number of items in the list.
>> BEGIN - First item sent, start of list.
>> END - Final item was sent, end of list.
The whole ordeal took 4 hours and was quite draining. It is official paperwork, and in Japanese, talking about finance related topics, which is plenty hard enough to follow in English. On the way home we stopped by the land again. Sense of accomplishment follows.
I went in on Monday to open a new bank account with the bank that we are getting the loan. Overall it went as expected, standard paperwork and options. At one point the teller called the bank representative that we dealt with on Saturday. During this conversation, she called me over and handed me the phone. The representative asked me if I could pop over once I had finished the account creation procedure. Once I received my new ATM card, and bank booklet, I walked over to the Loan Centre branch of the bank. It turns out that while filling in the forms, I had forgotten the 区 in 渋谷区 of the address. The health insurance form I had to fill in again, but the loan application it was acceptable to just correct, and hanko the correction. While I was there, they copied the new bank account details, and also my health insurance card. I will have to send in a copy of my last health insurance results as well, and one final issue. The proof of funds printout we had, was in the wife's name. This causes issues, even though we share accounts. So we will need to move the savings into an account owned by me, then do another proof of funds printout. Everything has to be exact in Japan.
Send RAW FTP commands to the remote server without FXP.One's
involvement. Typically used for SITE commands.
The bank also asked for some more proof of funds, but since the exchange rate with NZ is so poor at the moment, we explained we did not want to send more yet. The bank said we can just show the NZ dollar bank statement, they just want to make sure we have enough money to cover the shortfall at the end. The loan was approved on Friday morning for us, just a hint under a week since we did the paper work.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
>> MSG=<str> - RAW Command to execute.
=== Fiesta ===
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
The builders had a home-building-fiesta arranged over in Nihonbashi. It was a chance to get to see the various kinds of materials we could chose, both for outside and inside, the doors, the kitchen brand, bathroom etc. So that was very useful. There were many "options" (ie, extras if we want to pay) as well. Things like home-battery (using more night time power), solar power, security systems, new keycard door locks and so on. We also received the latest floorplans and a few freebees. We set a date to sign the contract with the home builders on July 27th. Building is set to start in Oct, and finish at the end of Feb. But before they start building there is a ceremony, with a shinto priest for good fortune of the land and house. Somewhere around September, where you also have to make sure the date is a lucky number. More on that as we approach it.
<< QUOTE|SID=1|CODE=-1|OK|MSG=Total users online: 1 Total active data: 0
<< QUOTE|SID=1|CODE=0|MSG=200 WHO command successful.
=== House contract ===
=== CWD ===
Jun 27th. Today we met at the model house with the builders to sign the contract to build the house. It is a preliminary thing that more of less specifies that they will build a house of size 124 m^2 and 3F, with basic floor plans. But the internal materials is not selected yet. We confirmed the 1F shutters, insect covers for all windows, and storage under kitchen counter. Which were our only concerns. The meeting started with showing of their ID again, that shows they are trained and licensed to read the contract to us, then going through each point one by one. Fairly standard items. After that I signed my name, and did the hanko ritual. We have one week to bank transfer the downpayment over (yay, doesn't have to hand over wads of cash!) From now it is expected that we have a meeting every week, to chose and decide each interior bit. As part of the building agreement, they agreed to start construction before Nov, and finish before Mar 23rd. (143 days). Once construction has started, they will call every week to give progress report. Although I doubt I will be able to not check it out (frequently) myself.
Change the Current Working Directory of the remote server.
They also checked that it would be OK for them to show the neighbours the design and plans for the house. What is interesting here is that they took the floor plans, and deleted all interior details. So just the outer walls, and floors. Not any inside walls, rooms or layout, as that is considered "private".
ie. "cd files/"
Transferring money wasn't quite as smooth as planned either, turns out there is a maximum furikomi limit, and the downpayment was just over it. So had to fill in paperform versions, and take a number. But in the end, that part is done.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
>> PATH=<str> - New desired directory. or:
>> FID=<int> - or: FID of directory.
=== Bank Loan Agreement ===
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
Friday 3rd we had the Bank Loan Agreement, at the Bank. It seems the previous meetings with the bank have been preliminaries and application for a loan. This meeting started at 10:00 and went for about 2 hours. Had to bring two more "Identification of certification of a seal impression" from the Cityhall, as well as the new bank account details. During this meeting we also went through the loan particulars, like fixed or floating interest, one large lump, or split the loan into two, and you can mix and match fixed vs floating. The choices of insurance was also settled, just death, or cancers, or heart related issues, or all three. The loan manager of the branch I opened the account at, also turned up to say hello. After that, all hanko stamping started. Including registering in Tokyo area and so on. It was decided that the 17th July to be the "final payment" day, at 10:00. This means the Bank will wire me the money into my account, and a fraction later, the money goes from my account to the land owner. There is a 3-man fee related to this, as well as 4-man fee of "stamps". So I need to have 7 man in the new bank account before the 17th. The first interest payment will start in August on the agreed upon date, and will start at 4man, but following months will be 6man (with health insurance). Since April next year (when there is a house there) the monthly mortgage payment will rise to the full 17-man. That is still just for the land, the house part of the loan will be settled closer to that time. We had an English translator with us from the realtor, but even with that, the whole ordeal is quite draining. We went to the pub for a pint and lunch.
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message. (Only final message
Had our first weekly meeting with the house builders, and our first surprise. A suggested placement of ceiling lights had been made on the floormap, and we found out that lights cost extra. Not sure how you envision living in a house without any lights. So with the bedrooms, they suggested the big round lights Japan is fond of, but we should get those from biccamera or similar shops, much cheaper. They will leave the cable in the ceiling for us. The rest of the lights, hallways, bathroom, stairs, LDK and kitchen, are mostly "downlights" and cost about 7,000 yen each. They had some master bedroom head-board lights suggested, but they were closer to 2man each. So, both curtain and lights apparently does not come with building a home. The next meeting is scheduled after the final-payment day, where first they will go measure the land and test the ground. The meeting will be about power-point placements, and kitchen interior selection.
=== PWD ===
=== final payment ===
Return the Current Working Directory path.
Today's meeting was at the bank to do the final payment of the land loan. Besides us, there was a representatives for; "Japan Fair Deals", the owner, and the realtor, all present, as well as our translator. At first I filled out some withdrawal slips, about 7 of them. For the various payments, fees, taxes etc. Couple of contract-like papers had to be filled in, and then hanko everything of course. Today included the realtors fee, shibuya registration certificate, but since we had already paid 3 million in down-payment, it mostly covered it all.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
The JFD representative informed me that I will receive a registered courier letter, where the bottom half of the letter is folded over to hide a secret serial number. This is your proof of ownership and should never be opened. You only use it when you sell the land, so presumably the seller had his opened today. We discussed if people keep it in a bank safe deposit box, but clearly that is uncommon in Japan. They all keep theirs at home, in "the safe".
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
There was a little bit of a wait, while everything was sorted out. We assumed the money would move hands by electronic wire transfers, and in most part it was. But, after a short wait, the bank staff came in carrying a large case full of envelopes. Of course it's done in cash!
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> PATH=<str> - The parsed current PATH. [1]
>> MSG=<str> - Command return message. (Only final message
unless you issue LOG)
So, the realtor had some 2 million, the seller about 3 million, the shibuya representative somewhere under a million, all cash in envelopes. So 3 guys start counting wads of cash. Straight out of a mafia movie. While this is happened, I get all the official receipts, with tax stamps, and hanko where needed. I also got my bank book back, showing a large transfer landing in my account, and a few seconds later, being moved to the seller's account. Once the cash was counted, the business was done.
[1] Warning, PATH is only returned if FXP.One successfully managed to
parse out the path from the reply. Some FTPD send non-standard
replies. If you find one of these, send me an example output string
and I can fix the parser.
I believe this means we are now land owners.
[ Example ]
>> PWD|SID=1
<< PWD|SID=1|CODE=0|PATH=/Giana_Sisters_GBA/|MSG=257 "/Giana_Sisters_GBA/" is current directory.
=== Swedish Sounding ===
=== SIZE ===
After we became land owners, they did a ground quality check, called Swedish Sounding (in katakana). The order of it all is a bit weird, I would expect all surveys be done before you buy it, but that is apparently not how it is done. We could tell immediately that something was up in this meeting as they were clearly hesitant and bearers of bad news. It turns out that the ground is very soft for the first 4m, after that it gets increasingly stronger. This means they have to dig down 4m for the foundation, and this is an extra cost. They guessed about 1 million yen, or so. There will always be extra costs with these things, at least this one we had heard hints about earlier. The rest of the meeting was a wash, since they had not really prepared anything else. To be considered hard enough, it has to have a rating of 4.0 or above.
Return the size of a file on the remote server. Not this will give
>> LOG - Send all strings with command, like SESSIONNEW
The meeting after that, they had gone out to find quotes for the ground problem, and picked one for us. The plan is to drill (thump?) down 27 carbon fibre steel 114diameter pipes, 9.5m into the ground. The quote was for about 1.2 million yen and would take about 3 days. So that is sorted. Then we had a look at all the floor samples, and picked our preferred style. Each floor could be a different style too. Since we were doing rather well, we went ahead and also picked the doors. I also popped into Yodobashi to talk to the aircon guys. Since we have to pick where to place them, the sizes and where the outside units go. For the 18 畳(jou) it was recommended I get a 23畳 aircon. Those units were in the price range of 25-30 man yen. For the other bedrooms, I can get "pair units" for those rooms above each other.
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> SIZE=<int> - The size of the file.
>> MSG=<str> - Command return message. (Only final message
unless you issue LOG)
We also asked about the possibility of simply paying for the house part of the loan with cash, instead of starting the second part of the loan, and would the bank be upset about that. It was explained to us that we can do that without any hard feelings, but since the house loan payments are actually split into 3, ie, the builders get a third at the start of building, a third in the middle, and the final third once it is done. We are better off letting the bank handle all that, and once we move in, simply pay the bank the whole loan in the first payment. Interesting.
[ Example ]
>> SIZE|SID=1|PATH=giana2k.xm.zip
<< SIZE|SID=1|CODE=0|SIZE=287688|MSG=213 287688
=== Power points ===
=== DELE ===
Todays meeting was to place the power points on the floor plan. We had 25 as part of the house (based on size of building) and that does not count the toilet, fridge, aircon and power points built into units. So generally, we placed 2 in each bedroom, hallways and around the LDK. We had 10 spare at the end so added some extra for outside roof balcony, in shoe closet, under the stairs etc. So all in all, 25 was about the right number. We could ask for more, for 4,000 each.
Delete a single file on the remote server. You can either issue by
name (relative path, or absolute path), or optionally use FID as
returned by DIRLIST.
We also added a door to the LDK area, as it was recommended by the aircon guy. Otherwise the cold air just escapes down the stairs. It was not a problem to add a door.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
>> PATH=<str> - Name of File. or:
>> FID=<int> - or: FID of file.
They had also suggested a fence between house and road, with the mailbox and door-bell camera, on a pole in front of the building. This took longer to discuss. But in the end, having the door bell far away from door and separate was a bit strange to us (but apparently, The Japanese can be uncomfortable entering the 'house' area before they have permission). We briefly looked at wall paper as well, which was a bit disappointing. Talk about endless selection of various shades of grey. The most subtle things ever, not entirely unsurprising for Japan I guess. But for 400yen per square meter more, we can get the "accented" wall papers which were definitely more what we want. One of the kids want a yellow room for example. 1 week cap in the meetings this time, and they teased us with the 1:50 map again, I think this makes it the 4th meeting the 1:50 map was mentioned :)
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
[[File:wallpapers.jpg|thumb|Wallpapers, the Grey]]
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message. (Only final message
unless you issue LOG)
=== 6th meeting ===
[ Example ]
>> DELE|SID=1|PATH=delete_this.bin
<< DELE|SID=1|CODE=0|MSG=213 DELE command successful.
More bad news today, of sorts. They had done more thorough check of the building plan with respect to the public-road-light rule. Tomorrow evening we are supposed to hear back from Shibuya regarding our planned building, but the builders think there will be a problem. We may need to go back 25cm from the road. If the neighbours had not over-built, we could simply do that. So we were presented with 2 alternate plans, changing things around. One makes the LDK part from size 18 to 15, which is not what we want. Changes to the middle floor does not matter too much. The second option kept the LDK mostly the same but the bottom floor was then shrunk. It is somewhat annoying that these things are not sorted out much sooner. Why did we "fix" the floorplan, and sign a contract that they will build a 121sq.m house, then later change both of that. I'm sure it's in the fine print, and yet, this could have all been worked out 2 months ago. They did revise the bill for a bunch of money back.
=== MKD ===
For now, we are waiting to hear back from Shibuya-ku although most likely the out come is that we need to tweak it. Don't know if we can talk to the neighbours about cutting their roof (house is empty after all) or go with one of the revised plans. Or just drop the whole thing and sell the land. Much thought needed.
Create a new directory on the remote server.
After that part, we looked at the windows, standard size for the thin windows is 02609, which is 026 / 09, ie, 26cm wide, and 090cm tall. We could also pick 036 for 36cm width, or 11 for 110cm height. Generally we like windows, so we opted for most of the small thin windows be the taller version. We asked about the 2F windows, if they can be larger, but you can not make them taller (falling out risk), but could make them slightly winder, so 16011 for those. We also chose frosted vs clear type of glass where it made the most sense. Should be noted that when they say "clear" glass, it is the glass with the small wire in it, making it grid-like (quake shatter proof).
[ Minimal Required Fields]
>> SID=<int> - SID of the session
>> PATH=<str> - Name of Directory.
After windows, we picked the colour of the kitchen cabinets, style of handle to open the drawers. Colour of the bathroom "vanity" unit, the bathroom walls and "accent", bathtub colour and toilet type. With toilet you can pick tankless, or with tank, if you want to wash your hands behind the toilet. But we have little hand washing sinks in the toilet rooms. And finally, the colour of my shower cabinet.
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message. (Only final message
So it would seem the reply from Shibuya came on Wednesday and we received an email from builders on Thursday night. It included the Shibuya report, which is the land survey and bunch of angles and numbers. The builders also included a revised floorplan, with our proposed changes implemented. We made the 2 rooms on the ground floor be one large one, and putting in a kitchenette instead. The additional cost of that is less than the refund for making the house a bit smaller. We also picked the outside materials, as in which brick(like) style, and which wood(like) accent. It was pretty hard to chose, and the only example we had is the colour image of the house mockup we get with the floorplans. After second guessing ourselves for a while, I asked if we couldn't do the colour mockup with our selection instead. They said that is no problem and we can pick 3 selections and they will do mockups. Just.. what if I hadn't asked? Hmm, in the end, we picked 2 each and they will email us the mockups.
Delete a single directory on the remote server. You can either issue by
We also don't really know the differences between the plastic and porcelain toilets. Which is better etc, and in fact, we may never even have used a plastic one. Apparently Toto's showroom has both so we will go to that and try them out.
name (relative path, or absolute path), or optionally use FID as
We also picked the tiles for the genkan.
returned by DIRLIST.
There was a page to sign as well, saying we are ok with the floorplan, ie, plan fixing - I guess they need one after the changes had to be done for Shibuya-ku. They also teased about the 1:50 plans for next time... again.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
>> PATH=<str> - Name of Directory. or:
>> FID=<int> - or: FID of directory.
=== Showrooms ===
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
>> MSG=<str> - Command return message. (Only final message
unless you issue LOG)
So while we were discussing the difference between a plastic or ceramic toilet with the builders, they suggested we go to the showrooms, one for Toto in Shinjuku, and Panasonic in Shinbashi. Since the Shinjuku one is a short bike ride away, we popped in to check it out. To our surprise it was really good, and fun to do even if you aren't building a house. See the different kinds of toilets, and bathrooms, showers, kitchens, cupboards, pantry, bedrooms, floor materias, doors, both outer and inner. We easily spent an hour in the first one, and decided to go pick up the kids and head out for the Shinbashi showroom as well. It gave us a chance to try out the wood we had picked out, and various kitchen colours, as well as, kitchen counter colours. Sit in the various bath tubs, and toilets to get a better feel for the size of our rooms. They had a few LDKs roughly in the size we will have, around 17, and it was encouraging that others had managed to fit kitchen, dining and living room setup in this space. The door selection was very much like Monsters Inc, slide out the door you want to look at. They had measurements everywhere, and you could move the kitchen drawers to the space your kitchen has (from 70cm gap to 160cm space between either side). We spent about 3 hours at the Shinbashi shop confirming selections, and making a few changes. It was probably the most fun we've had so far, building a house.
[ Example ]
I think we would have missed out had we not gone to the showrooms, making us wonder if perhaps we were supposed to be doing this ourselves. We sort of assumed that the builders would set this up. And to be honest, even as a tourist, if you are close to either one and have an hour spare, it is fun to see the way the Japanese houses are setup.
Todays meeting we actually got the 1:50 scale floormap, which isn't really much more than the 1:100 floormaps we received that had been doubled with a photocopier. Well, a few more details I suppose, but more for the builders than us.
[ Minimal Required Fields]
Each window and door, has a circular mark, like in the pictures. The floor height is considered at height 0, and since the genkan is a step down, the door in this case starts at -18, ie, 180mm down. It is a 1600mm wide, and 2000mm high from 16020. The SHS in this case means it is a sliding door/window, as opposed to SCS, which opens outward. The two kanji in the top right corner here means "clear" glass, as opposed to "frosted".
>> SID=<int> - SID of the session
>> CMD=<str> - Command and arguments to send.
The floormaps also included "S" for smoke sensors, and "T" for thermal/heat sensors. Which apparently comes with the house. Also ventilation points, and fans. Both the fans that are always on, and those in the kitchen.
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
We also got to see the sample outside picks we had made, in the form of 4 print outs. Various brick and wood selections we had done. One was easy to discard (unless you like the prison look), but after that it got hard to chose. We also went over the outside again, the white rocks and so on. As well as wallpaper, but it is not easy to pick which grey version we want, so we said we would let them know next time.
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message. (Only final message
It is somewhat amusing that in the last meeting, we mentioned the possibility of grass for the little strip of land before the road, and could we get a quote for it. To make sure we were talking about the same thing, we had to Google Image Search "grass" to show it. I guess it is that rare in Tokyo (well to be fair, there are many different kinds of grass, too). Today we received the quote for it, and to our surprise it was about 4万円 which is quite reasonable and cheaper than the white stones. So we will potentially have the only grass in Tokyo. We also received new printouts of the exterior selections we had made, and we made one selection in jest, which was the sun-toasted (yellow) bricks, with blue wood(-like tiles). Of course this ends up being the nicest option yet, mainly because all houses in Tokyo are essentially brown. Or some earth-tone colour, and most buildings pick the small tiles, giving it that "swimming pool" look to it. We were allowed to keep our brick selection tiles too. When it comes to the window frames, there was only aluminium, but we could pick colours. So no PVC choice or wood etc.
Rename a file or directory. Supply the originating name by either
passing FROM or a valid FID, as well as the resulting TO name.
We went over the floorplans again, this time to make sure the light switches and power sockets are ok, especially after the change in the plan on 1F and 3F. Some minor tweaks only. They also had placed TV outlets, so I guess that means we will be in the neighbourhood cable tv network. They had made basic plans for AC placement as well, and the power sockets for them. We informed them about our wallpaper selections, and also picked the tiles for shower, bath and toilet rooms. We brought the selection of front-doors with us as well, but the one we had an eye for, is part of the optional extra set. So we are waiting to hear what the cost of that would be, or we will simply pick the second choice there. The plans also included water tap outside on 1F, as well as water-proof power sockets. We asked about getting a water tap on the rooftop balcony.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
>> FROM=<str> - Source name. or:
>> FID=<int> - or: FID of entry.
>> TO=<str> - Destination name.
The builders also wanted to talk about the LDK big balcony door, as I have previously mentioned, we were after the sliding glass door, where you get an 100% clear opening when fully opened. But, since that door has to have the quasi-fire shutters, that means the shutters are quite large, including the section of the door that "hides", and sticks out a lot. Manual shutters. If we wanted to, we could change to the french-doors style instead, and the shutters are much smaller, and electric. If we wanted the french-door style (the "W" style), we could also go from 160cm to 180cm wide versions.
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
They also showed us a top-down outline of the land and house, to show the placement of the house inside the borders. Including where all access-covers, telephone-poles, neighbour's house windows. It is quite neat to have a map of all neighbours windows, on each floor, and see how the align with your own windows. The Y axis "zero ground level" is the height of the access-cover, and the house's floorline is then 130mm higher. Has the power, gas, water meters as well and their placement. Also picked the colour of the drain pipes, here we had a selection of shapes, from round, to angular, square etc. Also the trapdoors for access under the house, we picked the list colour of it, to be the closest to the floor selection.
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message. (Only final message
unless you issue LOG)
I brought up the toilet as well, if we could go up one model. To do that would be another 15万円 per toilet. I'll have to think about this. (But thinking is done on the toilet?)
We started with confirming the power socket placements, since we moved some around when the 1F plan changed. This was just to confirm that the changes we did the previous meeting is all correct on the floor plans. After that we had to pick the colour for the list, between window and accent. So between the two brick types we had picked. Just the white,grey,black trio to pick from though. We then moved onto the wardrobe insides, how we want the hanger, vs shelves, vs drawers, in each wardrobe; since they are all of slightly different sizes. We had seen a neat fold-down writing desk style in one of the showrooms and asked if that was possible. They will check for us, and get an estimate. I brought up the LAN placements and when is a good time to do that, and showed where I thought about having LAN sockets. I thought about 5 sockets, leading to the storage area under the stairs, for the routers and wiring But apparently for one LAN cable, it costs about 1.5万円, so the total would be about 9万円. Ugh, considering the LAN cable part itself is practically free. But much harder for me to write after the house is done (inside the walls that is).
Return the date and time of a file. (But not directories, according to
FTP RFC). The return data is in the format of yyyyMMddHHmmSS. For
example, "213 19970205115719". You can either issue by name (relative
path, or absolute path), or optionally use FID as returned by DIRLIST.
We asked again about the tap of RF, and they apologised for forgetting. I upgraded the toilet on 2F to one level up. Then it were finishing the meeting, and found out this was essentially the last meeting. heh, what? It's nice to know what are done, but also, are we sure we have done everything :) So we asked again to confirm we are getting an oven, the Finnish dishrack and all that. In the end, we made one more meeting, in two weeks, so that we can have final confirmation of our selections etc.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
>> PATH=<str> - Name of Directory. or:
>> FID=<int> - or: FID of directory.
They pencilled in the 14th of Nov as materials arriving at the land and building to start, so the ground ceremony to be about a week before, possibly on the 8th of Nov, as that is a lucky day. But it is the builder foreman who contacts the shrine to organise the date, so we will find out when. After the ceremony we are to go back to the builders showroom where we go over everything and do the final hanko to approve everything. We were shown the A3 size booklet they are making, which has all details in it, from colour, to wallpaper etc. In this sample we also learned that for our house, with the sunlight from road rule is, 10m/1.25. Ie, from centre of the road, go straight up for 10 metres, then "the slope of the plane is 1.25m rise for every 1m of run". About 51 degree angle..?
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
We also received a paper to fill in details about big furniture, washing machine, fridge etc, and to which room we were planning to move them. They will calculate as to whether or not it is possible to, for example, carry the washing machine up the stairs, or if it has to be lifted in through a window.
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message. (Only final message
unless you issue LOG)
[ Example ]
>> MDTM|SID=1|PATH=somefile.bin
<< MDTM|SID=1|CODE=0|MSG=213 19970205115719
=== (Real.Proper) Last Meeting ===
[[File:bathroomsim.jpg|thumb|Simulated Bathroom]]
Today we had the last meeting with the builders, and had a full house, so to speak. Going back a week or so before, we received a letter from Shibuya-ku about the land purchase. A form to fill out about the tax required. This looked quite complicated, so we had asked our translator for help, which is why she came to the meeting. With the form, it assumes you bought the land for commercial use, so by showing papers and contract, that we are building a house etc, using the size of the land in m^2, and total size of house in m^2, plus math, minus rebate etc, it turns out that the rebate is larger than the calculated tax, so we need not pay anything for the land, There will be another form to fill in once the house has been built.
== QUEUES ==
We also had one of the managers attend, who started the meeting explaining the issue about the water pipe. Since we want water to the 3F we need to get the wider pipe, as discussed earlier in here. To dig up the road, they need permission from the neighbours. Today we were told that, because there was an agreement with the neighbours and the land-seller (which needs to be redone with me as the requester, instead of the seller) they had assumed that getting the permissions updated would be "easy". Alas, the neighbour across from us has not been home for 2 months, and they are running out of time. It was explained that they will keep trying to get ahold of the neighbours before the deadline (mid Dec). Should that fail, they can bring in water from the Shibuya-ku part of the road, which is a hint further. But the builders will front the extra expenditure as it was their responsibility. Still there is time for things to go as planned.
=== QUEUENEW ===
I filled in my part of the agreement with neighbours, complete with hanko, with space for 3 more names and hanko should they get a hold of the neighbours.
Then the meeting started proper, we went through the selections starting from outside, and all went smoothly until the kitchen. They had colour printouts for each selection too, so we could see the bath, with our tile selection, wall cover etc. Quite nice to get a visual. As for the kitchen, it was still blue, although we had picked "mango yellow" in the previous meeting. Much apologising aside, that was remedied quickly. We mentioned that we would like to upgrade the 35L oven to the larger 44L oven (44L is almost 'western regular' in size). But, the 44L version is not an option with Panasonic, our first pick in kitchen, and we had to change to Toclas for that. Toclas had no yellow colour option, it was listed under optional extras. If we wanted that, the bigger oven is 8man more, and the yellow colour 10man. What pushed it over the edge though, was the Finnish style dish drying cabinet, Panasonic only had a rail for drying towels, whereas Toclas had a proper cabinet. So, we essentially redid the whole kitchen in this meeting.
Create a new QUEUE by associating two SIDs with it. These are
currently named NORTH and SOUTH as a means to refer to either one
uniquely without implying direction of transfer. (source and
destination does not work)
We also updated the light switches in 3LDK, as the wall the "middle set" was to go on, is a bit small. The quote for LAN cables was about 9man, so I trimmed it down to just a cable between 3F and 1F. The tap on the rooftop balcony apparently would need a pump to work at all, and that would cost about 40man. Since we really just want it for watering plants up there, it didn't feel like it was justified, instead we will get a quote for a rain water catcher.
[ Minimal Required Fields]
>> NORTH_SID=<int> - SID of the session, out of two.
>> SOUTH_SID=<int> - SID of the session, out of two.
[[File:view.jpg|thumb|"View" from nearby mansion (our land is behind the gap of the two buildings bottom-right]]
[ Optional Arguments ]
[ Returns ]
>> QID=<int> - Queue ID for queue operations.
There was one complication about the land. They had heard back from the Shibuya-ku road department, regarding the set-back. There was some clarification needed here, in that we were not talking about the setback on the north road, which is to follow the rules of Japan. But rather the road on the East side, which we had entered into an agreement with the neighbours (as part of the land purchase contract) to keep clear "for access". Not for cars, mind you.. there is no space to drive a car down that road, after our house. This was important though, since it was eventually explained that Shibuya-ku is "advising" that we pull the area of grass in smaller, to make sure it is 4m wide. But this is not classified as a 4m road, nor is it registered with shibuya-ku as a road. So it is suggested by Shibuya-ku to keep to 4m and not put grass there. However, I feel that as the contract does not specify 4m road, just that we will keep it clear for access, and that grass is much nicer than just asphalt, even if people were to walk on it. we will keep the grass there. The builders will simply not put down the little brick lip, that would separate the road and our "area".
[ Example ]
>> queuenew|north_sid=1|south_sid=2
<< QUEUENEW|CODE=0|QID=1|MSG=Queue created.
Shibuya-ku also had some forms for us to fill out, with more hanko. One was to acknowledge we had a meeting, discussing the (real) 4m setback. There was also a form to fill in the total amount of setback, and shibuya-ku will pay us back if the setback is large enough to justify it.
=== QADD ===
=== 2nd bank loan ===
Add a new items to a specified queue. This is quite a versatile
command which looks to take many arguments. As a command it has four
parts to it. Except for special QTYPE values, see below.
This was probably the longest period without any contact or meetings, which is only 3 weeks or so but felt like it dragged quite a bit. I did get contacted by the bank and they requested we come in on Sunday Nov 1st. Banks setting up meetings on Sunday eh. As it happens, this is for the 2nd part of the loan, the part that covers the house payment, which has the same paperwork as the land part of the loan. Loan and Health insurance papers, and so on. Also needs the hanko registration forms from Shibuya-ku and all that. Although since we knew all the details around it, it certainly went faster. It was amusing that they made the 35 year loan into 34 year and 6 months, since I was older now, and it needs to finish before I'm 80.
# The source information. The easiest way here is to use the FID option, if you have previously done a DIRLIST command. This will take the required source information from the directory cache. If FID is not used, or you wish to override information from the FID, you can specify the source information manually. The name of the item can either be specified by SRCDIR+SRCNAME OR SRCPATH. (SRCPATH = SRCDIR/SRCNAME). The extra SRC options, like SRCSIZE, and SRCREST are optional. Both are used for Resume purposes, as well as finally CPS calculations.
# The destination information. This is copied from the source. However, you can optionally override any of this. For example specifying a different DSTNAME would transfer and rename the file at the same time. The PATH is made up the same way as source, specify one of the two in: (DSTPATH = DSTDIR/DSTNAME)
# Queue position. This can be omitted for default queue positioning. However if the specific position is desired, you can use @=<int|FIRST|LAST> to specify Nth position, FIRST position or LAST position in the queue.
# Optional modifiers. The default behaviour of a SITE is to always RESUME unless specified otherwise using the "resume" option to the site definition. The default for a queue item is also to resume. You can override this default for THIS queue item by specifying "OVERWRITE" or "RESUME". The latter is useful if the site's default has been changed to OVERWRITE. You can also specify QTYPE for this addition, either due to manual queuing, or to override the FID type. If you get it wrong, the queue processing will also get it wrong.
To our surprise the builder's representative was also there, since in effect the bank will be paying them. She had printouts for us regarding the kitchen, and the new design with large oven etc. So that was a nice to receive. We were informed that the 8th is still the planned date to go to the builders place, and sign the final plans for building to start. Which will take about 2 hours. After that it is the shrine ceremony with the shinto priest, which apparently takes about 40 mins. It was whispered to us we should bring 4-man yen with us as a donation. The actual start of building is on the 14th, which is when they will drive down the foundation support into the ground. This is apparently also the day they put up the white board detailing the building information.
Alternatively, you can use QTYPE to set non transfer type items. At
this time, there is only type "STOP". If you issue QTYPE=STOP there is
no need to send information for 1), 2) or 4). Part 3) is optional.
There is currently a bug where you have to specify SRC= field with the
STOP item. It makes no difference as to which SRC you pick.
There has also been some discussion about the amount of money to "donate" for the ceremony. The builders has said 4man yen a few times, which stood out since 4 is generally thought of as bad luck number. Certainly with weddings you give either 3 man, or 5 man, depending on how close you are. (I think, but I'm mostly blind to social customs) Talking to 3-4 friends who recently built a house, they all said they donated 5 man yen. But the mother of one of those friends, mentioned that because they were with a big outfit (builders) there was an agreement in place where you only paid 4 man. Not sure if it's because the builders pay 1 man, or just a discount.. we will take 4 man as suggested but obvious carry a 5th should it become clear it is needed. :)
[ Minimal Required Fields]
>> QID=<int> - Queue ID
>> SRC=<str> - Specify which SID is the source. Either "NORTH"
We also went out to pick up the envelope to put the money into, since there are envelopes for up-to-1-man, then envelopes for 1-man-to-10-man range, and envelopes for 10-man-and-more.. so you wouldn't want to pick the wrong ones, right? There is a special pen to use to write on the envelope as well.
>> SRCPATH=<str> - Full path, ie, SRCDIR/SRCNAME in one.
>> SRCSIZE=<int> - Size of the queue item.
>> SRCREST=<int> - Restart point of queue item (files only).
>> DSTNAME=<str> - Name of destination file, OR obtained from source
>> DSTDIR=<str> - Directory path containing destination file, OR
obtained from source
>> DSTPATH=<str> - Full path, ie, DSTDIR/DSTNAME in one. OR
obtained from source.
>> DSTSIZE=<int> - Size of the queue item.
>> DSTREST=<int> - Restart point of queue item (files only).
>> QTYPE=<str> - Type of queue item. Either "directory",
"file" or "stop". [1]
>> RESUME - Resume file if possible.
>> OVERWRITE - Do not resume, overwrite destination
>> @=<int|str> - Queue position, int or FIRST/LAST strings.
=== Final Meeting ===
[1] More types will come. The default type is "file".
Today was the official final meeting, which meant going through the thick stack of papers, one by one. Double checking all selections. The outside tiles, framing, grass, front door, genkan tiles, flooring, wall paper, ceiling paper, indoor doors, direction of opening doors and windows, bath colours, toilet selection, toilet shelf selection, stairs, light switches, power points, balcony tiles, roof tiles, drainage pipes and on, and on. I had to hanko each page too. The foreman was there, who seemed nice, tried a bit of English here and there, which is encouraging. We were given nice printed pages with each selection cut out, or printed, so you can see it directly. We had an additional discussion about the kitchen counter, which is in addition to the built in kitchen bench. As well as the booth seating in the LDK, to make sure it opens for storage. And of course, the final price, with the extras detailed, and that too needed hanko-ing. The start date is set for Nov 14th, and official finish date is March 31st. For the ceremony this afternoon, it was explained it is set at 13:30, as today is a very lucky day, the shrine is very busy. So the next part is then...
[ Returns ]
>> QID=<int> - Queue ID
>> CODE=<int> - Command return status CODE.
>> ITEMS=<int> - Number of items in the queue
>> MSG=<str> - Command return message.
>> @=<int> - Position in the queue item was inserted.
>> SRCPATH=<str> - Original source path used (to identify QADD reply, and use "@")
>> DSTPATH=<str> - Original destination path used (to identify QADD reply, and use "@")
>> FID=<int> - If QADD was called with FID=, the QADD reply will also contain FID.
[[File:groundbreaking.jpg|thumb|Blessing the land (clean version)]]
What is the default queue position when QADD is called, or during file
transfers? When the API queues items, they will always be placed LAST
unless otherwise specified.
So I wasn't quite prepared for the level of "audience participation" required for the ground breaking ceremony. After the priest set up everything, naturally inside the "building part" of the land (they had outlined the house with string in advance), he had me put on a white robe, nay, cape! There were many offerings on a portable altar, like apples, daikon, carrots, aubergine, sake and salt etc, as well as our envelope of cash. The Priest did a couple of prayers at first, mentioning my name and family in the process, as well as blessing the land. He waved the stick towards us as well, and we were supposed to bow. He handed me a twig with lucky paper charms on it, which I had to turn a certain way, then place on the altar. Bow twice, clap twice, then bow again. The same process for wife and each child, followed by the foreman, the realtor and translator. Each got own twig and going through the ritual. Then the Priest gave me a wooden box filled with little square white pieces of paper. We walked to the Northern most corner, he did a blessing and I was picked up a pinch of papers to throw towards the corner, three times. Then for each corner of the house. Following that I was handed a hoe, and there was a perfect pile of sand/dirt on the ground (looked like mount Fuji). I was to stab the ground on the left, right then left. After that, the foreman got spade and did the same process. Following this, the Priest handed out small saucers for each one, and poured in a small amount of sake, including the kids. We did not have to drink any, but to pour it out on the land. I did sample a little, and then poured it on the dirt mountain.
As a default, files are added after all the (top) files, but before
the first directory. Directories are added after all files, but before
the first directory. (yes, it's the same). Which the exception of if
the name matches "fmovefirst" or "dmovefirst", then it is inserted
with "FIRST" position.
This concluded the ceremony of the land. The Priest handed us a plank with kanji charm inscribed on it, which we keep and put in the house when we move in. There was also an envelope attached it, which was given to the foreman, who will place it in the foundation of the house. We were given two large bottles of sake from the builders, and realtor. After this we rang on the neighbours doors to introduce ourselves and hand over a small gift. Not many neighbours were home today, but we met a couple of them. It was definitely an interesting cultural ritual, that we feel lucky to have had experienced.
This means, when it is expanding a directory, the queue ends up like:
=== Progress; Day 1 ===
FIRST
files that match fmovefirst
all other files
directories.
LAST
[[File:pipes.jpg|thumb|Nonsmoking pipes]]
=== QLIST ===
Leading up to the day that construction officially starts, we traded a few emails with the builders. The nearest neighbour had apparently made some demands. First demand was to move the house +10cm further away. The rule in Shibuya is that you have to leave 50cm gap, and we are actually building with 80cm gap. So they were asking for another 10cm on top of that. That is not really possible, amusingly because the house is already placed as far as it can go, as there is a clause in the contract when we bought the land, that we have to leave the East road clear for neighbours. So an agreement with the neighbours stops us from going with the demands of a neighbour. That aside, this particular neighbour's house is breaking the 50cm rule, so it is strange that they would bring that up.
List all queues on the engine, and their current states.
The second demand was no windows on the West wall (facing their place). Good luck with that, although to be fair, we have very few on that side, and they are all frosted.
The third demand was about the top of the stairs leading on to the roof balcony, called penthouse. They want us to move it from West wall, to the East wall. The cost involved in that means we wouldn't even consider it, but i do wonder if they thought that through. Sure it sticks up and is in the way as it is now, but change it around, it will be us hanging around on the rooftop balcony, looking down on their place.
That aside, at the land today we had some progress. We walked over as they were unloading and driving in a little work machine, used to force the foundation pipes into the ground. By lunch they had managed to finish 17 pipes already. When we popped over around 4, all pipes were done and the machine had been driven away again. The did the estimated 3 days of work in just one, so that is nice. Curious though if something will happen tomorrow (Sunday) or if that is an actual day off.
[ Minimal Required Fields]
We also received, in email, the approval to build from Shibuya-ku, official looking with many pages. Apparently we are given the hardcopy version once the builders hand the house over to us (involving a ceremony maybe?) I also paid a bit more attention of the pipes at the land, and did a quick count of 67 pipes. So I think the plan changed from 27 large diameter pipes, to apparently 83 of them (according to the builders). We have been told the foundation work starts on Thursday, so I guess Sundays are a day off.
[ Optional Arguments ]
We have been told that foundation work will start on Thursday, but we noticed someone has put up a wood make-shift fence on the land on Wednesday.
[ Returns ]
>> QID=<int> - Queue ID
>> NORTH=<str> - Name of the North site
>> SOUTH=<str> - Name of the South site
>> ITEMS=<int> - Number of queue items
>> STATUS=<str> - Current processing state
>> ERRORS=<int> - Number of items in the error queue.
>> KB/s=<int> - Transfer speed of last completed transfer.
>> SUBSCRIBED - Sent if client is subscribed to events from this queue.
It was an exciting day for sure, finally things are happening. When we popped into the land today, there was a proper fence advertising the building company, but more importantly, the building notice is up. The big white sign with my name and all the details involved. Such a small thing, but getting that sign up makes it all official. They started on the foundation, which interestingly is done in two separate parts. Our best guess for the gap in the centre is most likely room for the pipes (water, gas) that comes from the road. The two flat parts are covered in plastic, and you can see the good luck charm has been placed in it. Then they lined the area around the foot of the house with a solid fence, and poured in concrete as the "outer lip". They hooked up a power meter on one of the near poles, to use during construction. I have been told they will go and "test" the foundation many times, and it should be "done" by Dec 10th. I wonder if that means little will happen during this time.
Get the contents of a specific queue, all its queue items.
=== Progress; Day 14 ===
[ Minimal Required Fields]
>> QID=<int> - Queue ID
[[File:foundation2.jpg|thumb|Concrete]]
[ Optional Arguments ]
After about 3 days, they started putting in steel rebars, slightly raised, over the whole surface, then they poured concrete on the whole thing. They had further steel rebar outlining where the walls are to go, then placed boards around it, to pour in more concrete where the walls are to be. There is progress every day so it is nice to follow, and we go there quite frequently. Meanwhile, the neighbour with demands had her lawyer contact the builders, asking for a meeting, where she will not be present. Seems odd to not even bother showing? We are thinking about it, and waiting to hear advice from the builders.
Mostly been waiting for concrete to dry. The wood for the mold was removed and everything looks great. There was a delivery of more pipes, most likely for hooking up all the sewage. Meanwhile the meeting with neighbour's lawyer happened, and ended with us declining most of the demands. We did learn though, that when houses are close (like, 50cm) you can require that your neighbour's house's windows to be equipped with grilles (bars) across them. And if they do, we can demand the same back. It was recommended that we prepare a change of windows for it, in case they do ask for it. I always assumed that the reason so many houses in Japan have those window bars was due to insurance and burglary. But it seems to be related to neighbours and privacy. How peculiar. But we are getting rather tired of the neighbour and her behaviour, we have now asked for a quote to build a wall right on our border. Not out of spite, but rather to clearly separate our land from hers, as she is frequently using our land, and at the same time, demanding us to give more.
Get the contents of a specific error queue, all its queue items.
After the concrete set, they made molds for the porch and front entrance landing. More concrete poured into those and wait for set. After that we got the construction framework up, which is quite exciting. With a ladder on the side, I climbed up to first floor, but once you get there, it feels pretty high - and that is just one floor up. Then they put down beams on the concrete outline, and a layer of insulation followed by a layer of wood floor. Interestingly, the bath room is left open to the concrete foundation, I presume so that the bath can be "in" the floor a bit, and not have such a high climb into. An portable toilet arrived for the workers, presumably means there will be more than one guy working from now on. The wood for 3 walls are now up and a couple of inner walls. Just two days later and all walls are up, as well as the beams for the next floor, so you can, carefully, walk around on the 2F as well.
[ Returns ]
>> QID=<int> - Queue ID
>> QTYPE=<str> - Item type, directory/file.
>> SRC=<NORTH|SOUTH>- This item's source site is North or South.
>> SRCPATH=<str> - Full path of source
>> DSTPATH=<str> - Full path of destination
>> SERR_<int>=<str> - Source errors, incrementing, and the reason string
>> DERR_<int>=<str> - Destination errors, incrementing, and the reason string
>> BEGIN - First item sent, start of list.
>> END - Final item was sent, end of list.
Meanwhile, the neighbour has made demands of the builders, better cover between the buildings so her house doesn't get damaged, so now it is white sheets all the way to the top on her side.
[ Example ]
>> QERR|QID=1|BEGIN|ITEMS=1
<< QERR|QID=1|QTYPE=FILE|SRC=NORTH|SRCPATH=/Giana_Sisters_GBA//gfx_blocks.txt|DSTPATH=/tmp/tmp//gfx_blocks.txt|DERR_0=553 gfx_blocks.txt: Can't open for writing
<< QERR|QID=1|END
=== QDEL ===
=== Progress; Day 45 ===
Delete an item in the queue. If a client wishes to delete multiple
items, it is advised that the client pre-sorts the items list, and
send it with highest queue position first, in descending order. It is
an error to attempt to delete queue item at first position (@=0) if
the queue is active.
We basically have 1F and 2F done, with inner framework walls in place. 3F has a floor so we have been up there to check out the view. Even though you are basically looking at the neighbour's rooftops, it ends up being really nice, as from eye-level and up is just unobstructed view of the sky. It also helps that a lot of the neighbours have nicer roof covers, like the Japanese blue tiles. Feeling pleased about the LDK placement on the third floor. Due to it being the New Years holidays here, they boarded the house up. That is to say they nailed boards over the door and all the windows etc. So there is no sneaking in during the holidays. Oh well. Still, it is only a week. They seem to take 2 days doing the outer walls, then 2 days doing inner walls. Then about 2 days to do beams and floor for the next level. Surprisingly speedy construction. Potentially, after the first week of the New Year we can see the world from the rooftop balcony. We have been allowed to see up to 2F by the workers, so we have to remember to look impressed when we can go to 3F.
Please be aware that since deleting a queue item early in the list,
will affect queue items in a later position. That is to say, if you
intend to delete items 1,4,8 from the queue, and you issue 3 QDEL
commands "blindly" in the same order (1,4,8), the net effect will be
that queue items 1,5,10 are actually deleted. When queue item 1 is
deleted, item at position 4 is now 3, and item 5 is at position 4.
Either the clients need to be aware of the re-numbering and compensate
for later commands,
OR,
much easier is to sort the list in descending order before issuing the
QDEL commands. Ie, send QDEL commands in the order 8,4,1.
=== Progress; Day <mumble> ===
[ Minimal Required Fields]
>> QID=<int> - Queue ID
>> @=<int> - Queue position of item to delete.
[[File:tokyosky.jpg|thumb|Tokyo Skyline (collection of roof tops)]]
[ Optional Arguments ]
[[File:thebar.jpg|thumb|An LDK is born]]
One of the best parts during this phase, is that every day I go by the house on the way home, and something new has happened. So each day there is something new to discover. Essentially, the full frame is done. We have been on the rooftop balcony, and are very pleased with it. Totally worth getting, bit of Tokyo sky view, Shinjuku mostly, but Shibuya and Yoyogi as well. Surprisingly not very windy, presumably as we are in a valley. The sides are high enough so that it isn't so scary. Near chest height for me, so no feeling of tumbling over. The penthouse ends up with really high ceiling, because of the open stair part, and is quite nice in the sun. We are wondering if instead of "wasting space" by putting the mini-freezer up there, we should just put a beanbag there and read in the sun. Decisions, decisions.
[ Returns ]
>> QID=<int> - Queue ID
>> CODE=<int> - Command return status CODE.
>> ITEMS=<int> - Number of items in the queue
>> MSG=<str> - Command return message.
>> @=<int> - Position in the queue of item.
As for the LDK, it is complete, including the bench for sitting (just the wood frame mind you) and the kitchen counter. Nice and high, so it feels like a bar. Very nice indeed. We enjoyed a drink at the bar already. The house-frame worker guy bid his farewell, as his task was completed, and after that it is a different crew. While we were visiting, the windows were delivered, and one was placed in 1F already, the others stacked near where they should go. They are indeed double-glazed so that is nice.
[ Example ]
>> qdel|qid=1|@=53
<< QDEL|QID=1|CODE=0|@=53|ITEMS=0
The builders requested a meeting next Friday, at the house, and said it would take about 2 hours. It sound like we will confirm placements of power-points, and other selections.
=== QMOVE ===
Move an item in the queue from one position to a new position. It is
an error to move a queue item from, or to, the first position (@=0)
when a queue is active.
=== Confirming Details ===
[ Minimal Required Fields]
>> QID=<int> - Queue ID
>> FROM=<int> - Queue position of item to move
>> TO=<str|int> - New position, either <int> Nth place, or string
placement like in QADD. ("FIRST"/"LAST")
We met the builders at the house, and using all the floormap details, went through each floor, one by one. We checked the location of each power socket, light switch, light location, bench and seating, water connections etc. They had missed the floor power point, but we added that without issue. Also at this meeting was the electrician, and waterworks worker. It was useful to be able to talk to the professionals. The electricians made a few suggestions, adding a few light switches and a couple of lights in the kitchen. He also said he can leave the LAN cable ports without cables, if I wanted to string the cable along myself later. That's just fine by me. The electrician asked if we wanted 50A or 60A for the house, and suggested 50A will be plenty. Everything is Eco these days so hopefully that will be fine. The whole process took just under 2 hours to complete. They also brought along the design for the fence between us and one of the neighbour, and the estimate. They added our front-door today, surprisingly early I thought. Which comes with a concern that I will no longer be able to sneak in after hours.
[ Optional Arguments ]
They have started locking the door so that concern came true. I took a look at the key they use, thinking I could just get an "early" copy of my house key. However, they are using a "コンスキー", or, construction-key. It would appear that the locks have 2 modes, and during construction you can use the much-simpler (shorter) construction key for the workers. This appears to be so that the customer can be safe with the knowledge that nobody has had the real key, and a chance to copy it. Then on hand-over day, they flip the lock mode over, and only the real keys will work. Those are presumably held at the builders head office (foreman?). They seems to be specific to series of door models, or similar. There is a place to buy these keys online, but who knows how dodgy that will look? Still, challenge accepted!
[ Returns ]
>> QID=<int> - Queue ID
>> CODE=<int> - Command return status CODE.
>> ITEMS=<int> - Number of items in the queue
>> MSG=<str> - Command return message.
>> @=<int> - Position where item was inserted.
>> FROM=<int> - Position where item was originally from.
During the frame building, the progress felt very swift, each day had a new wall, or floor. These days it feels slower, since it is generally inside and gradual. Still, the outside of the house has been covered in a thin plastic like material, for rain proofing. All walls and ceilings have drywall everywhere, with insulation everywhere. The 1F glass doors have shutters above them, all electrical and pipes are in the walls and ceilings. The attached gas to the house, dug 2 holes (for some reason) and hooked it up. Took about half a day to do that. They put in the door to the shoe closet, the flooring "tiles" have been delivered but not placed yet.
QGRAB lets a client take control of an idle queue, and the queue's
sessions, if any. This is currently the only way to gain access to
sessions given away with the "GO" command. If the queue had any
connected sessions, the client should receive appropriate CONNECT
messages.
The key I bought on the Internet has arrived and works as hoped. It is a great relief to know I can hang out in my place whenever I want again :) They'd put in the 2F shower unit, as well as about half the doors inside. The ladder that goes to the rooftop balcony has been removed. Not entirely sure why though, perhaps they are to start the stairs there soon. You'd think stairs would be a higher priority that internal doors? Still, I believe we are still on schedule.
[ Minimal Required Fields]
>> QID=<int> - Queue id in question
=== Progress; 6 weeks to go ===
[ Optional Arguments ]
So they did the stairs next. They started with the top stairs from 3F to rooftop balcony, and start from bottom of stairs building up. Mostly gluing and fitting in each stair piece at a time. They seem pre-cut in advance maybe. He assembled the first half of the stairs in one day, and completed it the next. With dry-wall materials under it. We took the stairs for a test drive once he completed them. While they were being made, there was no access, even to the 3F floor. After that he has started the stairs from 2F to 3F, so at the moment we can only see 1F. But since they progress quickly, I think by the end of the week, all stairs will be completed.
[ Returns ]
Meanwhile, other workers are on the outside, using the "pink wood" to make vertical strips down the outside. I would guess they are to attach the outside tiles, maybe?
The bath room has been finished and looking quite nice if I may say so. The shower unit is the wrong colour, so we are just discussing that with the builders. Although, if it is a huge hassle to rip out and replace, I could probably live with it. But we will have to wait and hear back from them. We were surprised that the 2F shower room door, which also has a little room for a washing machine and vanity, which is a sliding door, is actually two sliding doors. That is to say, instead of a 1m wall, then a door, it is two sliding doors. We had not realised this, but this is probably a good idea. You get more access to the washing machine and the shelves above it, from both the hallway, and the shower room area.
>> QID=<int> - Queue id
>> ITEMS=<int> - Current number of items in queue
>> NORTH_SID=<int> - Session ID of North site, if connected.
>> SOUTH_SID=<int> - Session ID of South site, if connected.
>> NORTH_SITEID=int - Site ID of North site, for future SESSIONNEW
>> SOUTH_SITEID=int - Site ID of South site, for future SESSIONNEW
>> NORTH_NAME=<str> - Site name of North site
>> SOUTH_NAME=<str> - Site name of South site
>> CODE=<int> - Command return status CODE.
We have purchased all the AirCons, turns out they are on sale in Feb, since new models tend to come in end of March. So we got them really cheap. But no room to store those at the new house, so they are on the balcony of the apartment. Under cover of course.
All stairs are done, and it is nice to be able to change floors without using ladders. They aren't as cramped as I was worried they would be. The outside tiles are almost complete, they had started some time back, but because the started with the back wall, we had no idea that was ongoing. Half the front (last) wall to go, and that is complete. They started the kitchen in LDK as well, the fan and upper storage units go in first. We had a meeting at the place with the builders to stamp the last bit of the changes, in particular the building of the wall to the neighbour. While we were there, we also got the permission from the other neighbour to dig up the road for the water pipe.
=== QCOMPARE ===
We have a meeting scheduled for the middle of the week with a company to register the house with Shibuya-ku, which should enable us to get the complete address. More on that after it happens. I've been informed that 2/3 weeks before the handoff day, we are to meet at the bank and do the paperwork for the house part of the loan. This is also the time they expect you to have the final payment money in the account. The actual transfer happens on the handover day though. So basically you can square away the tedious red-tape, and the handover day is just a "fun day". However learned something interesting on this day too. There is a little square metallic box attached to the scaffolding, with pushable little tabs. Clearly not an alarm as it has no electronics. Turns out to be a mini-safe, and they store the construction-key in it. So that would be an alternative solution to the key problem, if buying it on the Internet wasn't an option. I do not (yet) know the combination.
Compare the two directories in the session cache against each other,
sending back list of FIDs that would be queued by FXP.One. This gives
GUIs an easy way to show which items would be queued, and processed in
a given set of directories. The compare function uses all the logic,
including skiplists, passlists, movefirst and skipempty. It compares
file sizes to ignore those of the same size, but highlights the side
with the smaller size should they differ.
The LDK kitchen went in, in just one day. Fan, to gas cooker, oven, kitchen sink, Finnish dishrack, cupboards and drawers. Just suddenly there, very nice. Very happy about the window between the top cupboards and the sink top. Having the 44L oven was a good choice as well. They have done great with the outside tiles as well, very close to being done. Just the rooftop balcony to finish. They even did the inside of the small balcony, which is really nice.
[ Minimal Required Fields]
>> QID=<int> - Queue ID
We also had the "registering" the house meeting, which was signing my name many times, on power-of-attorney papers, and then hanko all of them. Fairly straight forward, if I understand it correctly, we will be getting the new address in the next week or so. This registration will also send us papers which we are not allowed to open, which has a secret number in it for the day we sell it.
[ Optional Arguments ]
=== Progress; 4 weeks to go ===
[ Returns ]
>> QID=<int> - Queue ID
>> NORTH_FID=<int,> - Comma separated list of FIDs for the NORTH site.
>> SOUTH_FID=<int,> - Comma separated list of FIDs for the NORTH site.
I checked the house as normal one morning, and again on the way home. In that time they had removed all scaffolding which was quite a surprise. Finally we have a full view of the house and we are pleased with how it looks. They are working on the inside today, putting putty in the gaps in the wall, presumably before starting wallpaper work. Looks like work on the "vanity" in the 1F bathroom. (sink+mirror unit)
=== QUEUEFREE ===
We also started looking at the AirCon Installation problem, and got some quotes. Yodobashi wanted something like 3-man an AirCon so that our upper ceiling when it came to quotes. We had a guy visit the house to look around, and pointed out that two of the AC powerplugs were too high (would be in the way of the AC unit). He contacted the builders while he was there, and managed to arrange to have the two power plugs lowered by about 5cm. The builders electrician came in the next day and moved them down, so that was quite efficient. The AC Installer guy also pointed out the insulated hose between the two AC units, cost something like 3,000yen per meter. Three of our ACs are on 2F with outside units on 1F, so that is a cost to factor in. He also recommended getting AC hose covers on the outside, even though that is even more expensive, it is better insulation, and looks cleaner on the house. In the end, we will most likely go with this guy, his quote is good, but more than he was able to communicate with the builders and organise the problems and make things right.
Release an existing queue, release its sessions, and queue items.
Wallpapering is almost complete, and the mess they made on the floor explains why the floor was covered so well, and completely. They also laid tiles on the balconies, which makes it look real nice. Even the part you can not step onto has tiles.
[ Minimal Required Fields]
>> QID=<int> - Queue ID
The builders have asked for a nairankai day, about a week before hand over. That seems to translate as "private showing", but I guess it is to check over final details. It is said to take 2 hours.
[ Optional Arguments ]
[ Returns ]
>> QID=<int> - Queue ID
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message.
=== Progress; 3 weeks to go ===
[ Example ]
>> QUEUEFREE|QID=1
<< QUEUEFREE|CODE=0|QID=1|Msg=Queue released.
There was a couple of days with nothing happening, then it was all back on again. Over the weekend we went to look at the typical Japanese round ceiling lights. 90% of them are LED, so that is nice. Of course they are also measured in the tatami mat size (畳), so if your room is 8 mats, you look at the lights for 8 mat and above. Not too much variation really, but there are a few with nicer patterns and designs. Most come with remote controls, so you can change the brightness, and warm-to-natural-to-cold kelvin levels, as well as other things. Some have people-sensors, so they can turn off automatically, a lot of them let you change the RGB colour separately, and advertise things like "twilight blue for calming evenings". The one we looked at, for the 17畳 LDK, although we went for a 12畳 sized light since it is for the living room half of the room, the kitchen has its own downlights, comes with remote and smartphone app. Since you clearly want to be able to control the light from the phone, that goes without saying. We eventually managed to pick the 5 lights we need for the various rooms, but left purchasing for later. Stopped by the house to have a look around, which we generally do once or twice a day. I wonder if I will miss having a place to go every day once I move in? post maternal depression of some kind? Who knows... as we were walking around the foreman showed up for his rounds, and explained the electrician is due in the next two days, so if we could have the lights ready, they will install them for us. So back to the shops we went to pick up all the lights.
=== GO ===
The electrician is indeed there, all the light switches, and wall power plugs have been delivered, so they are busy installing those. The outside power plug has already been installed. There was also a worker there making concrete, and covering the outside concrete, and the bottom part of the house, including the porches. Perhaps tiles too? There was also a gas boiler for the hot water delivered, sitting in the 1F room.
Issue "GO" to a queue. Request FXP.One engine to start processing the
queue and its items. The client loses ownership of the two SIDS at the
issue of the "GO" command. You may no longer issue commands directory
to the SIDs. Once a queue is idle, either from the QC|EMPTY message,
or after issuing the STOP command, the client can issue the "QGRAB"
command to receive controls of the SIDs, if still existing.
A day later and most downlights have been installed on 1F and 2F. The electrician was working in the shoe closet, most likely on the fuse box. The closets now have shelves in them, which is very nice. There had been a decent sized delivery as well, toilets and vanity with sink.
[ Minimal Required Fields]
>> QID=<int> - Queue ID
The next day there was a whole lot more done. Light had been installed, including those we had bought. Light switches everywhere, as well as power points. All the downlights and the closet lights, and the stair lights are installed. Both toilets are put in place, as well as the flooring in the toilet room. Toilet has a sink as well, and the remotes installed on the wall. The rooms had smoke detectors, and the kitchen also gas sensor. Shower room had its sink in place, as well as extract fan installed. The main door intercom had been put up on the wall in the LDK, as well as the outside camera unit. The kitchen booth seating was finished, with openable seats. The gas boiler remote controller is on the wall in the kitchen. The rooftop balcony has its light and powersocket installed. The rail hangers have been put up on the small balcony. The Japanese use these to dry the washing. AC 200V powersockets also installed where needed. The main breaker/fusebox is installed in the shoe closet.
[ Optional Arguments ]
>> SUBSCRIBE - Subscribe to queue status (QS) and queue changes (QC)
I mailed the translator to ask what, if anything, I should bring with me to the bank loan meeting in 3 days. When I get the reply, it has the usual cityhall documents required, like the hanko certificate, and family registry. But apparently they need to be under the new address, which we have yet to receive. So hopefully we will get the address in the next 2 working days, so I can go to the cityhall and change my address, then update the hanko certificate and family planning, and the gaijin card, and... so on. I wonder what would have happened had I not mailed and asked what to bring? We received the new address later in the afternoon.
[ Returns ]
>> QID=<int> - Queue ID
>> CODE=<int> - Command return status CODE if failed.
>> MSG=<str> - Command return message.
Alas, going to the cityhall to change address, they just said you can not before you move, against the rules. So unsure why they asked me to change the address before the registered stamp certificate. Either way, I will take the documents they want with current address, and if they need them updated, we will just have to send them after we move.
[ Example ]
NTT called back about the Internet hookup, I used the English line for it which is nice, so you have a translator on the line with the normal NTT engineer. The first available date they had is the moving day, which is what I was hoping for. I made sure to ask for the fastest available too, so it will be a 100meg fiber to gigabit fiber upgrade as well.
>> GO|QID=1
<< GO|QID=1|CODE=0|MSG=Queue processing started.
=== Progress; 2 weeks to go ===
We had the bank meeting today, which is presumably the last paper-worky event. It was somewhat surprising that talking to the bank staff and loan manager, about the cityhall papers having old address instead of the new. They just went "oh yes, you are supposed to lie about the move in day" and laugh. So it turned out everyone lie and say they have already moved in, so they can get the address updated and put on the certificates. I feel a little uneasy to lie to the government on official paperwork, but that is just what you are supposed to do. One wonders though, if everyone does it, and everyone knows about it, maybe they should just change the rules. It is amusing that they are accepting of breaking the rules, once it is clear everyone is in on it. Anyway, the bank meeting itself was filling in my name many many times, and hanko afterwards. There was not much decision making needed, as we had already decided the loan particulars in the previous bank meeting. We already picked the insurance type for the house (fire, earthquake, 3rd party etc), and to be covered for 10 years. Also included filling in the bank transfer slips for the large amount of money at the end. This transfer happens automatically on the hand over day. We got some freebees from the bank again. Yay tissues boxes!
=== STOP ===
While I was signing papers left and right, the bank staff and our translator were discussing something with the transfer, and this discussion kept going for quite a while after, probably close to 20 mins. We asked what was going on at that point, and it turns out that they were discussing who should pay the 540 yen ($5) transaction fee, us or the builders. It is amusing that we can move a $300,000 sum and we are discussing $5. This is also reflected in the total price of the house, which ends in 2 yen. There is no rounding-up going on here. Although, surely we aren't the first people who got a loan with the bank, why don't they not just know the answer?
Issue "STOP" to a queue. Request FXP.One engine to attempt to stop processing the
queue and its items. There are currently three types on STOP levels, the default is
"SOFT", which will stop once the current transfer is complete. "HARD" which will attempt to send the FTP command 'ABOR' to both FTPDs to gracefully interrupt the current transfer. (local client might need ABOR support added) Finally, the "DROP" method which will log out of both FTPDs and hence forcing the transfer to stop. Once the queue processing has stopped, the FXP.One engine will issue a "QC|IDLE" command, after which the client can issue QGRAB.
After the bank meeting we went back to cityhall, and changed address, since we "moved yesterday", and get the official certificates finally. Dropped those off at the bank on the way home. With that, we should have had all the red taped squared off, and its ready to go.
Power has been attached to the house, so we played around with the lights and the light switches in the evening. We definitely have enough lights, which is a relief. Quite a number of light switches though, wonder how long it will take to memorise them. The insect nets are up everywhere, some on the inside and some on the outside.
[ Minimal Required Fields]
>> QID=<int> - Queue ID
Today we had the nairankai, which is a big walk through of the house checking everything. Pointing out if anything is missing or different. We found a missing power socket for the 1F fridge, some dent in the window and little minor things. That gets itemised on a paper which I sign at the end. We were also shown how everything works, and how to clean each thing and when. The cupboards up high have earthquake locking latches which was interesting. During the walk through we were also told that the neighbour we have had hassles with, her lawyer has asked to come look from our balcony, to see if her roof is dirty and if the construction company should pay to clean it. Silly, but we are ok with the lawyer looking.
[ Optional Arguments ]
>> HARD - Send FTP 'ABOR' to FTP daemons
>> DROP - Drop connections to FTP daemons to cancel transfers.
=== Progress; 1 week to go ===
[ Returns ]
>> QID=<int> - Queue ID
>> CODE=<int> - Command return status CODE if failed.
>> MSG=<str> - Command return message.
All the things in the nairankai has been fixed and they have started the outside ground work. Digging and putting down irrigation first, for the drains and so on. Then a small wall to outline the area with fresh dirt. There is water in the house but we think it is just temporary, as we have been told the road work for the proper pipe will happen in 2 days. The upgraded toilet on the 2F has a sensor to open the toilet lid when you enter it, but it is far too good. Even just sticking your head into the hallway will trigger it. Guess there is a manual to read to change that. The entrance, both inside and outside now has tiles, and have been done nicely. The tiles go all the way into the shoe closet too. The fuse box is in there too, and one of the fuses is an earthquake fuse. If there is a quake over magnitude 5, the buzzer will go off for 3 minutes, and if you do not reset it in that time, it will cut the power. We also tested the smoke detectors, which are very loud of course, but amusingly they aren't just the traditional annoying beep, but rather they speak. "there is a fire!" In Japanese of course. 6 days to go.
The big glass doors in the LDK now have electric shutters, so it's fun to play with those buttons, as well as learning the intercom's camera and various zoom features.
=== QC ===
We have started arranging everything for the moving day, and managed to make everything to happen all on the same day, so it will be a busy day. All the deliveries, fridge, tv, bench and so on, the moving company with boxes, the crane to lift the big fridge up, internet and cabletv people. It will be a busy day. 5 days to go.
This is a receive-only command, sent by the FXP.One engine when there
is a Queue-Change. It is only sent if the client requested to
SUBSCRIBE to a queue, either using the "GO" command, or the "QGET"
The neighbour is at it again, they found out we are building a wall, and only on their side. Heh. So there were some demands made there, not sure if we will do anything about it or not. Maybe if they promised to never hassle us again...
[ Minimal Required Fields]
The neighbours lawyer came by the house as arranged, and builders were there with their lawyers. Not sure what the outcome is yet, but I believe the plan is to continue as planned, as nothing can be changed at this time. The fence has been started though, and the water works staff came by to drop off some equipment. Apparently they are starting the main water work the next day. 4 days to go.
[ Optional Arguments ]
That appears to be the case, 5 trucks and a whole lot of equipment, including a small digger. It is amusing to note they had to lift aside the grass that was planted yesterday, so it is clear the water hook up is late. We stopped by Shibuya-ku's waste management office, to pick up a blue-net-box for the rubbish. Apparently they are stopping by on the moving-in day, to take a picture of where the rubbish will be, for the garbage truck workers to know where to pick up from. Heh, all done properly I suppose. The final sink on the 2F toilet has been installed, so inside should be all complete now. We still haven't heard the outcome of yesterday's lawyer conclave, but the fence has not changed. 3 days to go.
[ Returns ]
>> MOVE - Item has moved to a new position. Comes with
FROM= and TO= keys.
>> REMOVE - Remove items from queue. All items with higher
position are decremented by one. Uses @.
>> INSERT - New item inserted into queue. Uses @, SRCPATH,
DSTPATH, QTYPE, SRCSIZE.
>> EMPTY - Empty queue, processing stops.
>> IDLE - Queue moved into IDLE state, either from QTYPE=STOP or
in response to a STOP command.
The water has been done, and road looks reasonable again, and there is a blue lid ground box for the main water supply. There is no hot water yet, but I did notice the gas water boiler power cable wasn't plugged in, I guess they do that on the hand-over day. The work on the fence has stopped, apparently the neighbour wants to talk to us (now? seriously?) So I guess we will see how that goes.The builders have agreed to wash her wall and roof. I suspect, just as a way to end the discussion, and move on. We got our first junk mail in the mailbox today, so that is "in working condition" I suppose. Otherwise, everything is ready for tomorrow's hand off. Checking the loan bank account, I can see that the loan transfer came in, and the total for the house went out to the builders. As well as two smaller transfers for fire insurance, and some stamp tax. In theory, I guess we have officially paid for the house now. 2 days to go.
The hand over day, We met the builders at the house, and went through the list of things that was incorrect during the nairankai inspection. They had fixed everything so that was not an issue. They handed over the keys, and demonstrated that as soon as I used a real key in the lock, the construction key no longer works. Definitely a nice system. There were a few papers for me to sign and hanko. One that said they had fixed things, another saying we owed them zero money. We are now home owners! Woo. We then did aisatsu, which is going to and greeting the new neighbours with a small gift. We had a tiny bag of rice for each one, all wrapped nicely with the correct words. Luckily, nearly no neighbours were home at the time so we could leave it in their mailboxes. Then we started moving things ourselves. First we got the boys to move the beds (bought new beds so they were in boxes, ready to go) and we did the aircons. Those things we bought after the moving-company quote and were not part of it. Hard work for sure, but took only three trips with the trolley (daisha). We also moved our mattresses, as we wanted to sleep there the first night.
When the FXP.One is expanding a directory, it may send a large amount of '''QC|INSERT''' items to the clients,
so in an attempt to assist clients to avoid frequent display refreshing, the engine will add the tag '''|EXPANDING''' to some items, and
follow with a '''QS|REFRESH''' command to indicate the directory expansion has completed. It is considered an optimisation and can
be ignored.
During one of the self-moving runs we ran into the neighbour we have had problems with, who do not want us to build a fence, and the reason we are building a fence. The builders had informed us that she wanted to talk to us about it, and that they had stopped building the fence until then. The builders told us that we can resume building the fence whenever we want, next week, next month, next year. So that is nice, so we can have a trial run without a fence to see how it goes. Talking to the neighbours we explained, as best we could, that we only built the fence due to her behaviour and if she just could be a bit more "normal" we would prefer to not have a fence. So that is how it is now, no fence, but can build it anytime it is needed.
=== QS ===
It was a hard day moving things ourselves, and we had a picnic upstairs in the LDK (no seats yet). After that, the family tried out the 1F showers, and more importantly, Jacuzzi bath which was fantastic. Having the small fridge for the guest room delivered on this day was also a great move. 1 day to go.
This is a receive-only command, sent by the FXP.One engine when there
is Queue-Status information to relay. Client can safely ignore this
command as it does not reflect on any queue changes. It is merely
meant as a way for clients to be able to track progress of a queue
being processed. It is only sent if the client requested to
SUBSCRIBE to a queue, either using the "GO" command, or the "QGET"
(Not yet implemented).
All QS messages are related to the item at the top of the queue. So
"@=0" is implied.
=== Moving Day ===
[ Minimal Required Fields]
Sure miss curtains! Not the privacy thing, but the amount of light, both at night from the near by apartment block, but also once the sun rises. It was exciting to sleep in the new house though, finally. I tried out my 2F shower stall, absolutely no complaints there. Interestingly though the default toilet seat heater setting seems to be furnace. Need to figure out how to change that.
[ Optional Arguments ]
Ushka went to the old apartment to handle the movers there, and I stayed at the house for all the work and deliveries. First to arrive were the aircon installing guys, I showed them were we wanted them so they could get started. They worked from 9 to about 1 in total. At 9:30 the guy from the appliance shop showed up, to check if the new washing machine would fit. He measured and did his thing, explained it would be very tight and recommended the slightly smaller model. He mentioned something about a phone call.
[ Returns ]
>> START - Started processing the item at the top of queue.
SRCPATH=<str> - Included for human readability.
>> SRCCWD=<str> - Changed to new directory on source
>> DSTCWD=<str> - Changed to new directory on destination
>> MKD=<str> - Created new directory on destination
>> XFRACT - File transfer has started (received 150)
SECURE=<yes/no>- Was Secure Data negotiations successful.
REST=<int> - Are we resuming this file
SIZE=<int> - Final source size (from SIZE command)
>> XFREND - File transfer finished (successfully, 226).
TIME=<int> - Duration of transfer [1]
KB/s=<int> - Estimated speed of transfer [1]
>> FAILED - Attempted transfer failed
SERR=<str> - Error reasons (source failed)
DERR=<str> - Error reasons (destination failed)
COUNT=<int> - This failure count.
At around 10:00 NTT showed up to wire the fiber Internet connection. I explained the electrician ran a cable pipe from the outside corner of the house to under the stairs, so they setup the ladder to start the work. As they started to climb the ladder, the aircon guys drilled through the wall into the outside plug connector, so it broke and fell to the ground. So they had a small conversation about that, and what to do. Nobody had a replacement part for the unit, but it was clear the aircon guys should be fixing it. NTT guys left at the point and said they would be back later in the day after the aircon construction was completed. The rest of the aircon installation went without issues, and they glued the outside unit back together again. They finished around 13:00 and got paid and left.
[1] Please be aware that we can only measure the time difference
between the 150 FTP message, and the 226 FTP message as received by
FXP.One. This may not reflect the actual time taken for the transfer,
subsequently the KB/s computation is based on said time, and will most
likely only be an estimate. The shorter the duration of a file
transfer is, the more inaccurate the speed computation will be.
Around 13:40 the moving trucks showed up, two of them parking outside the house. A few things got moved in, but quite a leisurely pace. Once the fridge was out, the crane guys showed up. (Piano movers according to the truck). I thought they were to move the moving tracking out of the way, but apparently that was not needed. The crane went up, carefully between all the wires between the poles, picked up the fridge and hoisted it up. The crane operator had a wireless controller which looked like fun. Once the fridge was above the 3F balcony fence, they just pulled in the bottom, and the fridge came in diagonally. The crane guys left, took less than 30 mins. Then the movers started taping up the walls and protecting the floor to move things in. Moving in did not finish until about 18:00, and near the end we just stacked all the boxes (for each floor) in one location (on each floor). We had 3 friends pop by during the day too which was nice and one had brought some potatos and duck, which made for the best dinner yet. (Been all takeout lately).
The NTT Internet guys came back at 18:00, and wired up the fiber to the house, hanging it on each pole on the street, out to the main road Threading the cable into the house was no problem, so they must have fixed the outside device properly. He spliced the cable into the modem, did the required tests and declared all OK. Naturally it didn't work when I plugged in the wifi router, but reading the mails from the ISP, it became clear I had to change the login. Yay, Internet. The boys had been hanging out for youtube access all day, and of course their desktops do not have wifi, so I just ran a cable over the stairs to their room so they were happy. Quick dip the Jacuzzi again, and I unwrapped the TV to check it was there.
Boxes. Boxes everywhere. Slowly unpacking things, but naturally spend quite a lot of time looking for things in boxes. But there are not too many to go. I did the LAN cabling finally, to connect 3F and 1F, and found the electrician had actually run the LAN cables, I just needed the end plug. No more LAN cables in the stairs, but need to dig out the other wifi router as the signal isn't quite strong enough to reach 2 floors, consistently. There are many pleasing things with the new house, the LDK is not as cramped as we feared, definitely the best floor :) Bath and both showers are fantastic, all sinks have the pull-out type taps which are excellent for cleaning things. I fixed the toilet sensor by taping over 50% of the sensor, low-tech solutions are often the simplest. Now it only triggers once you enter the room. I think it is designed with the idea that the toilet door is always closed, when not in use. But since the cat litter box is in there, we have to leave it open. Made some temporary curtains out of cardboard boxes, but also started putting up curtain rails etc. So they are being put in, just taking a while. Definitely need a brush of some kind for the stairs. The roombas take care of the main floors. Noise is a bit different, compared to a solid apartment building. You can hear people walking around one floor above, and flushing / water drains. Nothing too loud, just out of range. Sliding doors are a bit louder to open/close when people are sleeping compared to swing type.
Request to receive the QS and QC commands from a processing queue. A
client may subscribe to as many queues as it wants, including those
not started by itself.
The outside porch light has a motion sensor in it, so now we tend to leave it on (and it switches off automatically). Annoyingly the hot-water tends to turn itself off, and you have to push it on again. Might need to find the manual for that. Had the 1F aircon on to heat a little, since it is the coldest part of the house. When you turn it off, it told me I used 14.5 yen of power. Heh
[ Minimal Required Fields]
>> QID=<int> - Queue ID
Also started changing address everywhere, tedious but required I suppose. I wasn't sure I had to change the loan bank account as well, but they were still using the old address so most likely. The best change so far was UFJ, you can swipe your ATM card and enter new address on the computer screen. Yay.
[ Optional Arguments ]
>> TOGGLE - If already subscribed, issue un-subscribe instead.
We have also noticed that if you sit still on 3F, watching TV or reading computer, you can feel the trains as they pass by. The first earthquake will be interesting. The house is built well for it, it is just different compared to a large concrete apartment block that we used to live in.
[ Returns ]
>> QID=<int> - Queue ID
>> MSG=<str> - Command return message.
>> UNSUBSCRIBED - If issued TOGGLE the result was to be un-subscribed.
We had our house warming party, so that is the first time the house has had any capacity of people. The builders and realtor translator came too (we invited them) and of course friends and family.
[ Example ]
>> SUBSCRIBE|QID=1|TOGGLE
<< SUBSCRIBE|QID=1|CODE=0|MSG=Subscribed
I went to the old apartment with work, to meet the owner and hand over the keys. They took endless photos of the place, I suspect because they have never seen the apartment before (It has changed owners while we lived there). No major issues since we have lived there longer than 10 years, and besides, any issues will be handled by work. There was a surprise in that they took rent from the paycheck, but that turns out to be because I rent from work, and way back when I started working here, and moved into the apartment, I didn't need to pay anything upfront. So I am in fact paying rent after living there. Next salary should be full amount.
=== UNSUBSCRIBE ===
The CableTV company came by, and I showed them the cable outside the house that the electrician left. He also asked where the distributor is, which I didn't really know. But usually they are above the bath or in similar ceiling space. I remembered seeing the electrician fiddling with cables above the 2F shower (and the fan is in the wall, so it wasn't hooking up the fan). Sure enough, there is the distributor. The CableTV guy also asked if there was power socket there too, rooting around in the ceiling for a brief moment found there was indeed a power socket. That electrician did everything right! Due to it being April, the moving season in Japan, the Cable guys are very busy, so the first installation date I could get is for 2 weeks later. I am in no hurry with Japanese TV, so that is acceptable.
Stop being subscribed to a queue.
Shibuya-ku workers came by to measure and check what needs to be done for the road re-paving. We do not know the date that will happen yet, but it is at least moving forward.
[ Minimal Required Fields]
>> QID=<int> - Queue ID
We had a relative come stay to help make curtain for us, so it has been full on with the curtain making, and putting up curtail rails. Not something I had done before. I have also been trying to run another LAN cable, and I was unsure how the cable duct layout is, but through trial and error I have managed to figure out how it runs. There is still a lot to do around the house.
[ Optional Arguments ]
[[File:kitchen.jpg|thumb|Yellow Kitchen]]
[ Returns ]
>> QID=<int> - Queue ID
>> MSG=<str> - Command return message.
[ Example ]
>> UNSUBSCRIBE|QID=1
<< UNSUBSCRIBE|QID=1|CODE=0|MSG=Unsubscribed
=== First Month ===
The CableTV guys came, hooked the cable among the poles just like the Internet guys and connected to the house. TV and STB box setup on 1F and working. Luckily because the STB comes with a B-CAS card, the TV one is now spare, and I could plug it into the TV on 3F. So TV works on 3F as well, without the Cable channels of course.
=== QCLONE (v1.7) ===
Everything with the house is fantastic, some minor things which we realise now. Like we have lights in the stair "landings" which we just never use, the lights from the stairs, and hallway we use and that is more than enough. (Plus the small windows) There is no area that we feel is dark, even at night. There are a couple of power points that should be in a slightly different location. Love the flooring we have but you definitely get more things under your feet. But that just ends up in the carpet instead of you have carpet. No regrets there.
Take a created queue (idle or active) and make an exact copy of the queue. If source queue is active, connect both sides and start processing. Some clients refer to this as "add another thread".
We bought the 2F washing machine, and it had a 2 week wait for delivery. It cost an extra 3,000 yen to take it up one floor, but otherwise was no problem at all. I had already removed the sliding doors, mostly to learn how to remove sliding doors, and how to put them back, but also to make it easier for them to install it. It was the last major thing for the house, so it is all complete now.
[ Minimal Required Fields]
>> QID=<int> - Queue ID
One of the windows on 1F no longer wants to open, seems to be stuck internally. But we received the post card from the builder for the first checkup, so we will simply mention it then.
[ Optional Arguments ]
>> START=<yna> - Start processing (Y), do not start processing (N), or copy source (A). Default is (A).
>> SUBSCRIBE - Also subscribe to queue processing notices.
Also a worker from Shibuya came and rang the door bell, to make an appointment for when they will come and inspect the house. To ensure it matches the registered blueprints, and built to size etc.
[ Returns ]
>> QID=<int> - Source Queue ID, same as given.
>> NEWQID=<int> - Newly created clone Queue ID
>> MSG=<str> - Command return message.
Otherwise, we are just living in our new home and enjoying everything.
<< QCLONE|CODE=0|QID=1|NEW_QID=2|Msg=Cloned and created queue
<< CONNECT|SID=3|SSL
<< IDLE|SID=3
<< CONNECT|SID=4|SSL
<< IDLE|SID=4
<< GO|QID=2|CODE=0|MSG=Queue processing started.
[[File:booth.jpg|thumb|Booth Seat]]
== ADMINISTRATIVE COMMANDS ==
=== QUIT ===
=== Three month checkup ===
Disconnect from the FXP.One engine. The client can also just close the connection without worry.
The builders came around for the 3 month checkup, we had one broken window (in that it did not want to lock) and they had that fixed in about 10 mins. The rest of the time they checked around the place, making sure everything is ok. They explained that some of the wall paper seams may separate a little bit, but they wait until the house has gone through all 4 seasons, so at 1 year checkup they will fix those sort of things. Went through what filters need to be cleaned, and going through those items. We also have had a door added in front of the 1F stairs.. we were a bit nervous as to whether or not it would look nice, but as always in Japan, they have excellent quality and it fits right in. We also got our first land tax, which comes in 5 bills, and you pick which one you want. Either you use the full-year, or the first of 4 quarter bills. So that ended up being quite easy and pretty much exactly what we expected, about 32-man for the year.
[ Minimal Required Fields]
Mean while, life in the new house is fantastic.
[ Optional Arguments ]
[[File:toilet.jpg|thumb|Welcome, Master!]]
[ Returns ]
>> Will disconnect on you, how rude.
[ Example ]
>> QUIT
<< Connection closed by remote host.
Around this time, one of the LED light bulbs broke, specifically one of the stair lights going between 2F and 3F. Ordinarily I would just go out and buy a new light, replace it and life goes on. But, it is usual for LEDs to break this soon, quite shy of 40,000 hours. So I contacted the builders to see what the deal was, are the light still under warranty (at least a year one would have thought). Sure enough, the lights are indeed under warranty, so we compared schedules for them to come visit. A few days later they came around and confirmed that it was indeed broken - I can understand this, making sure that it really is broken and not some other silly thing, or bad wire etc. I have done plenty support for people were it really was just CapsLock on. But since the light is broken, it needs to go back to the vendor, so they would call me in the next week or so to arrange an appointment date. The builders left the broken light in the wall-light, which surprised me.
=== HELP ===
Sure enough, a week later I get a call for the manufacturers, and we make an appointment for a few days ahead, and when that day comes, he checks the light is broken, and replaces it with a new one. Confirms the switch turns the light off and on a few times, does the usual excessive apologising, and we are done.
Display available commands at this privilege level.
If another light breaks, I might just go out and buy a replacement myself. :)
[ Minimal Required Fields]
I received a phone call and the girl said "I have finished your registration". Which was odd, and took a while to click into what the conversation was about, mostly due to language differences. Eventually it became clear it is about the new house registration in Tokyo, and I have this vague recollection about meeting with lawyers, signing a bunch of power-of-attorney papers etc. So apparently, that took this long to do. The upshot of it is that they are sending the invoice for the work. Perhaps that means it will show as a house in Google Maps soon?
[ Optional Arguments ]
The lawyers sent an invoice for the registration which came to about 26man, which I think we were told about a while back.
[ Returns ]
>> MSG=<str> - Command return message.
>> CODE=<int> - Command return status CODE.
[[File:grass.jpg|thumb|First grass in Tokyo]]
[ Example ]
>> HELP
<< HELP|CODE=0|Msg= QUIT HELP WHO SHUTDOWN SITEADD SITELIST SITEMOD SITEDEL SESSIONNEW SESSIONFREE
SIZE DELE MKD RMD SITE REN MDTM QUOTE SUBSCRIBE UNSUBSCRIBE.
=== Five month checkup ===
=== WHO ===
I received a letter from Shibuya-ku which asked me to call to make an appointment for the inspection, and have a list of papers available for perusal. Including photo copies of the floorplan, and heightmap of the house. So apparently we haven't had the official inspection after all! I called them and made an appointment which was all fine. On the day, it was a young salaryman, and an older woman who showed up. We went through the "box of important papers" to find what they wanted, mostly from the paperwork that the lawyers couriered back. The ticked a bunch of things on their papers, things like number of sinks, washing machines, kitchens, toilets etc. In fact, they paid more attention to the sinks (and their sizes) than they did the doors (we were worried about doors, since we had added one since moving in). They also said the penthouse was 1.6m^2 "over size" and apologised. Seems odd that the builders we used would go over-size. It was also explained that last years land tax was 34man because we had no building. This/next years land tax is close to 7 man, and with the house comes to about 10man a year. That is for the first 5 years, as the 1.4% tax is halved to 0.7%.
Display a list of users connected to this FXP.One engine.
[[File:floor2F.jpg|thumb|2F floormap]]
[ Minimal Required Fields]
[ Optional Arguments ]
Thinking about things I would change, I do remember a conversation with the electrician as it if I needed 3-prong wall sockets or not, for the normal wall sockets that is. Since things like fridge, aircon and toilet power sockets are 3 prong of course. At the time I declined, since I've never had any specific need for them in normal rooms, like bedroom. But looking at getting ethernet-over-power (powerlink) which apparently can work better/faster with 3-pronged sockets. Oh well. But ultimately, I don't ''want'' powerlink, I really wanted LAN connectors in all rooms, and should just have paid the 10man to have it installed. Oh well :)
Received a postcard from the builders to pick our convenient dates for the one year checkup, and a short list of issues we want to have looked at. Nothing major really, but the fresh air vent in LDK that came off the wall a little bit, and was fixed, is again coming off the wall. We had some powercuts during summer, perhaps running too many ACs or something, so we changed to 60A. Strangely, we still had 2 cuts in January, and the last one was with almost nothing on. We will bring that up as well. One of the wooden walls holding in the soil for the grass is looking a bit dodgy. That is the 3rd item we listed, but over all, we have had a great time living in our home. We had the builder guy who did the door in front of the stairs come in, and put up our forest mural wall paper, so it is a little less white in that room.
Change the login password on the FXP.One engine. This is strongly encouraged.
Figured out that I can lift the windows off completely, and clean both sides. They are surprisingly heavy. We are also coming up to doing the TAX for the firsts time, with the loan included, so more on that in a bit.
[ Minimal Required Fields]
>> OLD=<str> - Old/current password of this login session.
>> NEW=<str> - New/future password for this login session.
I had to go to the TAX office about 3 times, mainly because I did not have all the papers I needed. The first line I waited in is for checking all the papers needed and working out the numbers. They had 4-6 table area with a helper switching between them, and you could ask for English speaking helper. Once that was finally cleared, I had to queue to use the computers, similar setup but not sure there was any English speakers there, but at least they are there to help. What is amusing about the computer input section is that it has an image of the salary TAX payments you did the previous year, that you received from the employer, then arrows pointing to where to input those numbers. It is the perfect example of scanning in the information automatically, instead of having every person do manual data entry.
[ Optional Arguments ]
It was complicated and repetitious but eventually it was completed and sent to the printers. Getting a nice chunk of cash back, for 10 years. After that I went to the 3rd place, where you swipe the card given on the printers to unlock the printing. Once everything is printed, it is placed in an envelope and put into the correct mail slot, for us, the Shibuya-ku one. That completed the TAX, and it will be automatically sent to work each year for the next 10 years.
[ Returns ]
>> MSG=<str> - Command return message.
>> CODE=<int> - Command return status CODE.
Finally we got to the 1 year inspection day, and it looked like a person from a contractor showed up, I suppose the builders do not do the inspections themselves for whatever reason. We showed the outside part where the grass is and the wood holding it in is buckling. Took pictures and the details. He checked all the things outside, including using binoculars for the high areas. When he checked the main water meter, it was showing we were using a tiny bit of water even though everything was off. Turns out that the old washing machine seems to be leaking a tiny bit. Shutting off its water tap makes the outside meter stop. Good to know. We showed the vent coming off the wall on the 3rd floor, and talked about the powercuts for a while, since we changed to 60A should have stopped all that. Inspecting the main breakers, he pointed out that the main fuse is still 50A, so it looks like we changed to 60A with the power company, but did not know that the main fuse needs to changed too. Amusing, hopefully they will come and fix that for us soon.
[ Example ]
>> SETPASS|OLD=admin|NEW=newpass
<< SETPASS|CODE=0|MSG=New password has been set.
<< SETPASS|CODE=1502|MSG=Login incorrect
It is amusing that we spent the weekend before the inspection cleaning the house, as if we had to prove we were worthy of living there. Still, it is nice to have a clean house.
=== SHUTDOWN ===
Shutdown the FXP.One engine have it completely exit.
...
[ Minimal Required Fields]
The wall outside the house (wood, holding in dirt) was really not looking good, so we contacted the builders to talk about that. They suggested we do a concrete block wall, about 10cm high instead, like we have between house and neighbour. Of course they sent a quote of about 33man. But we thought we would check with our local handyman, who did the AC installation, forrest wall papering, and LAN cable wall plugs. His quote was about 21man, and more importantly, he felt we should do a straight line wall, instead of going in a bit for the oversized/abandoned building. So it feels like we reclaimed some of our land and it looks fantastic. Took about 2 days to complete. Handyman sent us a slab-of-beer gift as thank you for the job. Japan is great.
[ Optional Arguments ]
>> LASTCLIENT - Only shutdown if THIS client is the last one.
The "other" light bulb in the stairs broke, and I sent an email to the builders to see what the deal would be this time. I did not really want to go through the whole thing again with multiple appointments etc just to change a bulb. But they informed me that since it is past one year, it is not covered any more. Few, bought the same bulb on amazon and it is done.
[ Returns ]
>> Might disconnect on you, how rude.
The tax rebate came back and was a big wad of money, so it is nice to know that works. The second year tax payment was tiny, something like 19man. Not sure they made a mistake, but when we paid it, they seemed to think it was right. Not complaining about a smaller bill than expected!
[ Example ]
>> SHUTDOWN
<< SHUTDOWN|CODE=0
<< Connection closed by remote host.
Latest revision as of 02:34, 23 May 2018
Documentation for FXP.One API commands and protocol. This documentation file is maintained at
http://www.lundman.net/wiki/index.php?title=Protocol and exported to other formats. This documentation is purposly maintained rigorously as to aid all client developers of FXP.One.
Connecting
WELCOME
When you connect to the FXP.One server, you should receive a greeting
string, similar to:
Pay special attention to the SSL flag here, since if it is enforced,
and you attempt plain text authentication (which will fail) you are
exposing the user and password.
The "version" is the server version and build
The "protocol" is the protocol version, which you can check to be of
the same Major type as your application knows.
The "SSL" field can be "disabled", "optional", and "forced".
SSL
Initiate SSL challenge. This is sent by clients requesting the
remainder of the session to be in SSL. This requires that FXP.One
engine's WELCOME message is either "forced" or "optional".
[ Example ]
<< SSL
>> SSL|CODE=0|Msg=Attempting SSL negotiations.
AUTH
Send USER and PASS for authentication. This requires a valid user and
password pair already registered on FXP.One. If FXP.One was started
with no user database files, it will create one with the account user
"admin" and password "admin".
[ Minimal Required Fields]
>> USER=<str> - USER name
>> PASS=<str> - PASSWORD
[ Minimal required fields ]
>> NAME=<str> - Name of site. Not used by engine, need not be unique.
>> HOST=<str> - Hostname of remote FTP server
>> USER=<str> - User name for authentication on remote FTP server
>> PASS=<str> - and password
[ Optional Arguments ]
>> PORT=<int> - Optional PORT of remote FTP server. Default 21.
>> PASSIVE=<yna> - Use passive for directory listings? [See YNA type]
>> FXP_PASSIVE=yna - Can this remote FTP only take PASV, or PORT?
>> CONTROL_TLS=yna - Attempt SSL/TLS on Control channel?
>> DATA_TLS=<yna> - Attempt SSL/TLS on Data channel? Site needs CCSN feat
>> IFACE=<ip> - Optional IP to bind() to.
>> IPORT=<int> - Optional PORT to bind() to.
>> DESIRED_TYPE=yna- Binary or Ascii mode transfers. [See YNA type]
- AUTO and engine will set Binary for transfers.
>> RESUME=<yna> - Attempt to Resume before Overwrite.
>> RESUME_LAST=yna - Re-queue items needed resume last in the queue.
>> PRET=<yna> - Send the extended Pre-Transfer command before transfer[1]
>> FSKIPLIST=<str> - File skip list [2]
>> DSKIPLIST=<str> - Directory skip list [2]
>> FPASSLIST=<str> - File pass list [3]
>> DPASSLIST=<str> - Directory pass list [3]
>> FSKIPEMPTY=<yna>- Skip empty files
>> DSKIPEMPTY=<yna>- Skip empty directories
>> FMOVEFIRST=<str>- Pattern file matches to force queue at top
>> DMOVEFIRST=<str>- Pattern directory matches to force queue at top
[1] AUTO means it will use this feature if it is reported by the
remote FTPD in the FEAT/features command reply.
[2] Uses fnmatch(3) syntax pattern matching. Most file globbal you can
do on the command line, including "*?[]", but excluding "{}". String
consists of slash separated patterns. eg "*.dat/*readme.txt*".
All skiplists, passlists and movefirst are processed on the DESTINATION site.
[3] Opposite to skiplist. The default is for passlist to be empty,
which is the equivalent of "*". A syntax like "*ENGLISH*" would ensure
only entries which matched string would be queued, and others are
dropped. Uses same pattern syntax as skiplist.
[ Extended Optional Arguments ]
As a special feature to the clients connecting to the FXP.One engine,
we also allow for storing of own, arbitrary, key/value pairs. As long
as the "key" is not the same as any of the above keys, or that of the
predefined reserved keys. (eg. "TYPE", "END")
>> <str>=<str> - Store extra client information.
For example:
"...|extrafield=somestuff|OS=Unix"
[ Returns ]
>> SITEID=<int> - Site ID of created site.
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message.
[ Example ]
>> SITEADD|NAME=local|host=localhost|port=56688|user=mp3|pass=mp3|passive=1|fxp_passive=2|control_TLS=2|data_TLS=2|extrafield=somestuff|OS=Unix
<< SITEADD|CODE=0|SITEID=12|Msg=Added successfully.
[ Caveat ]
It is recommended that all clients that wish to store information
in the site database, to prefix their key values with a unique string,
perhaps the name of the application. For example:
lundfxp_sitecmd_1=SITE WHO
lundfxp_lastlogin=015368281
SITELIST
Lists all defined sites.
[ Minimal Required Fields]
[ Optional Arguments ]
>> SHORT - Send only short list (siteid + name)
>> SITEID=<int> - Send only specified siteid. Sends no BEGIN/END keys.
[ Returns ]
>> SITEID=<int> - Site ID being displayed.
>> NAME=<str> - Name of site. Not used by engine, need not be unique.
>> HOST=<str> - Hostname of remote FTP server
>> USER=<str> - User name for authentication on remote FTP server
>> PASS=<str> - and password
>> PORT=<int> - Optional PORT of remote FTP server. [1]
>> PASSIVE=<yna> - Use passive for directory listings? [See YNA type]
>> FXP_PASSIVE=yna - Can this remote FTP only take PASV, or PORT?
>> CONTROL_TLS=yna - Attempt SSL/TLS on Control channel?
>> DATA_TLS=<yna> - Attempt SSL/TLS on Data channel? Site needs CCSN feat
>> IFACE=<ip> - Optional IP to bind() to. [1]
>> IPORT=<int> - Optional PORT to bind() to. [1]
>> DESIRED_TYPE=yna- Binary or Ascii mode transfers. [1]
>> RESUME=<yna> - Attempt to Resume before Overwrite. [1]
>> RESUME_LAST=yna - Re-queue items needed resume last in the queue. [1]
>> PRET=<yna> - Send the extended Pre-Transfer command before transfer[1]
>> FSKIPLIST=<str> - File skip list [1]
>> DSKIPLIST=<str> - Directory skip list [1]
>> FPASSLIST=<str> - File pass list [1]
>> DPASSLIST=<str> - Directory pass list [1]
>> FSKIPEMPTY=<yna>- Skip empty files [1]
>> DSKIPEMPTY=<yna>- Skip empty directories [1]
>> FMOVEFIRST=<str>- Pattern file matches to force queue at top [1]
>> DMOVEFIRST=<str>- Pattern directory matches to force queue at top [1]
>> BEGIN - First item sent, start of list.
>> END - Final item was sent, end of list.
[1] This information is only sent if the current value differs from
the default "AUTO" type. Or, in the case of strings, where the string
is defined (not-empty).
[ Example ]
<< SITELIST|BEGIN
>> SITELIST|SITEID=2|NAME=localhost|HOST=127.0.0.1|PORT=21|USER=mp3|PASS=mp3|PASSIVE=1|FXP_PASSIVE=2|CONTROL_TLS=2|DATA_TLS=2|optional_variable=roger moore
>> SITELIST|SITEID=1|NAME=localhost2|HOST=127.0.0.1|PORT=56688|USER=mp3|PASS=mp3|PASSIVE=1|FXP_PASSIVE=2|CONTROL_TLS=2|DATA_TLS=2
>> SITELIST|END
<< SITELIST|SITEID=2
>> SITELIST|SITEID=2|NAME=localhost|HOST=127.0.0.1|PORT=21|USER=mp3|PASS=mp3|PASSIVE=1|FXP_PASSIVE=2|CONTROL_TLS=2|DATA_TLS=2|optional_variable=roger moore
SITEMOD
Modify an existing site's key/value pairs. Specify as many items as
desired to be changed. Items not specified in the command are left as
they are. To delete a key/pair, send the key with an empty value
field. For example "key=".
[ Minimal required fields ]
>> SITEID=<int> - Site ID of created site.
[ Optional Arguments ]
>> NAME=<str> - Name of site. Not used by engine, need not be unique.
>> HOST=<str> - Hostname of remote FTP server
>> USER=<str> - User name for authentication on remote FTP server
>> PASS=<str> - and password
>> PORT=<int> - Optional PORT of remote FTP server. Default 21.
>> IFACE=<ip> - Optional IP to bind() to.
>> IPORT=<int> - Optional PORT to bind() to.
>> DESIRED_TYPE=yna- Binary or Ascii mode transfers. [See YNA type]
- AUTO and engine will set Binary for transfers.
>> RESUME=<yna> - Attempt to Resume before Overwrite.
>> RESUME_LAST=yna - Re-queue items needed resume last in the queue.
>> PRET=<yna> - Send the extended Pre-Transfer command before transfer[1]
>> FSKIPLIST=<str> - File skip list [2]
>> DSKIPLIST=<str> - Directory skip list [2]
>> FPASSLIST=<str> - File pass list [3]
>> DPASSLIST=<str> - Directory pass list [3]
>> FSKIPEMPTY=<yna>- Skip empty files
>> DSKIPEMPTY=<yna>- Skip empty directories
>> FMOVEFIRST=<str>- Pattern file matches to force queue at top
>> DMOVEFIRST=<str>- Pattern directory matches to force queue at top
[1] AUTO means it will use this feature if it is reported by the
remote FTPD in the FEAT/features command reply.
[2] Uses fnmatch(3) syntax pattern matching. Most file globbal you can
do on the command line, including "*?[]", but excluding "{}". String
consists of slash separated patterns. eg "*.dat/*readme.txt*".
[3] Opposite to skiplist. The default is for passlist to be empty,
which is the equivalent of "*". A syntax like "*ENGLISH*" would ensure
only entries which matched string would be queued, and others are
dropped. Uses same pattern syntax as skiplist.
[ Extended Optional Arguments ]
As a special feature to the clients connecting to the FXP.One engine,
we also allow for storing of own, arbitrary, key/value pairs. As long
as the "key" is not the same as any of the above keys, or that of the
predefined reserved keys. (eg. "TYPE", "END")
>> <str>=<str> - Store extra client information.
For example:
"...|extrafield=somestuff|OS=Unix"
[ Returns ]
>> SITEID=<int> - Site ID of created site.
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message.
[ Example ]
>> SITEMOD|SITEID=1|fskiplist=*ENGLISH*,*COMPLETE*|fskipempty=YES
<< SITEMOD|CODE=0|SITEID=1|Msg=Modified successfully.
[ Caveat ]
It is recommended that all clients that wish to store information
in the site database, to prefix their key values with a unique string,
perhaps the name of the application. For example:
lundfxp_sitecmd_1=SITE WHO
lundfxp_lastlogin=015368281
SITEDEL
Delete an existing site.
[ Minimal required fields ]
>> SITEID=<int> - Site ID of created site.
[ Optional Arguments ]
[ Extended Optional Arguments ]
[ Returns ]
>> SITEID=<int> - Site ID of created site.
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message.
[ Example ]
>> SITEDEL|SITEID=12
<< SITEDEL|CODE=0|MSG=Site deleted.
[ Caveat ]
Sites aren't actually deleted, just not saved to disk. This means
active sessions using said siteid created before the SITEDEL command
was issued will continue to work.
SESSIONS
A session refer to a site connection. The API will ask for a new
session to a specific site (specified with SITEID) and a session will
be created. If the connection is lost or closed, _the session is
closed_. The API will have to request a new session if so desired.
SESSIONNEW
Request a new session to site, returning a SID to session.
[ Minimal Required Fields]
>> SITEID=<int> - Which remote server to connect to, from SITELIST.
[ Optional Arguments ]
>> LOG=1 - Normal login is silent. With LOG the API received
all verbose messages.
[ Returns ]
>> SID=<int> - Value of the new SID for all future commands with
sessions
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message.
[ Example ]
>> sessionnew|siteid=0
<< SESSIONNEW|SITEID=0|SID=1
<< IDLE|SID=1
SESSIONFREE
Release a session, and disconnect from remote host.
[ Minimal Required Fields]
>> SID=<int> - SID of the session to close.
[ Optional Arguments ]
[ Returns ]
>> SID=<int> - SID of the session closed.
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message.
[ Example ]
>> SESSIONFREE|SID=1
<< SESSIONFREE|CODE=0|SID=1|MSG=Success
ASYNC
Is not a command but client need to be aware that there are messages that
come in at any time.
<< CONNECT|SID=1
Send once a session has successfully logged in and is ready to answer
queries. Initially it was thought that IDLE would be enough, but
clients will generally want to auto-trigger some commands upon
connection establish, so we provide this event.
<< IDLE|SID=1
Site is idle, ready for more commands. Informative only as you can
always issue commands, they will be queued.
<< DISCONNECT|SID=1|CODE=429|MSG=Undefined error: 0
The session was disconnected. Any further references to the SID (in
this case "1") will result in an error.
<< LOG|SID=1|MSG=
You can request a SESSIONNEW to be logged (LOG), or, most of the
commands take an option "LOG" to specify that logging is desired
during the execution of said command. This means the engine will
forward all messages from the remote FTPD to the client. For example:
>> CWD|SID=2|path=/requests
<< CWD|SID=2|CODE=0|MSG=250 CWD command successful.
>> CWD|SID=2|path=requests|LOG
<< CWD|SID=2|CODE=-1|MSG=250-REQUESTS ADMIN: roger
<< CWD|SID=2|CODE=-1|MSG=250-
<< CWD|SID=2|CODE=-1|MSG=250-RULES: Please use format of REQ- and FILLED-
<< CWD|SID=2|CODE=-1|MSG=250- and please do not dump single files into
<< CWD|SID=2|CODE=-1|MSG=250- root as it just make the folder look untidy!
<< CWD|SID=2|CODE=-1|MSG=250-Available space: 14676.22 MB.
<< CWD|SID=2|CODE=0|MSG=250 CWD command successful.
FTP COMMANDS
DIRLIST
Request a directory listing from remote server/session.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
[ Optional Arguments ]
// Optional: PATH, ARGS, RAW, CACHEOK, LOG
>> PATH=<str> - Additional path element [1]
>> ARGS=<str> - Additional list options [2]
>> RAW=<int> - Include entire list line in FID reply.(unparsed)
>> CACHEOK - If cache is populated, avoid remote server
>> LOG - Send all strings with dirlist, like SESSIONNEW
[1] Warning. It is not recommended that you use this to supply
different paths as the internal cache engine will get mighty confused.
[2] Some "ls"/LIST options will break the internal parser. For
example, "-1" would remove the long listing style.
[ Returns ]
>> SID=<int> - SID the dirlist reply is from.
>> FID=<int> - File ID of this item. For QADD.
>> NAME=<str> - Name of Directory OR File
>> DATE=
Send RAW FTP commands to the remote server without FXP.One's
involvement. Typically used for SITE commands.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
>> MSG=<str> - RAW Command to execute.
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE. (If FTP reply < 300) code=0
>> MSG=<str> - Command return message. (Only final message
unless you issue LOG)
[ Example ]
>> QUOTE|SID=1|MSG=SITE uptime
<< QUOTE|SID=1|CODE=0|MSG=200 Uptime: 2d, 1h, 52m, 50s.
<< IDLE|SID=1
>> QUOTE|SID=1|LOG|MSG=SITE WHO
<< QUOTE|SID=1|CODE=-1|OK|MSG=200- [ WHO ]
<< QUOTE|SID=1|CODE=-1|OK|MSG=Total users online: 1 Total active data: 0
<< QUOTE|SID=1|CODE=0|MSG=200 WHO command successful.
CWD
Change the Current Working Directory of the remote server.
ie. "cd files/"
[ Minimal Required Fields]
>> SID=<int> - SID of the session
>> PATH=<str> - New desired directory. or:
>> FID=<int> - or: FID of directory.
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message. (Only final message
unless you issue LOG)
[ Example ]
>> CWD|SID=1|PATH=Giana_Sisters_GBA
<< CWD|SID=1|CODE=0|MSG=250 CWD command successful.
PWD
Return the Current Working Directory path.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> PATH=<str> - The parsed current PATH. [1]
>> MSG=<str> - Command return message. (Only final message
unless you issue LOG)
[1] Warning, PATH is only returned if FXP.One successfully managed to
parse out the path from the reply. Some FTPD send non-standard
replies. If you find one of these, send me an example output string
and I can fix the parser.
[ Example ]
>> PWD|SID=1
<< PWD|SID=1|CODE=0|PATH=/Giana_Sisters_GBA/|MSG=257 "/Giana_Sisters_GBA/" is current directory.
SIZE
Return the size of a file on the remote server. Not this will give
errors on directories on most FTPDs.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
>> PATH=<str> - Name of File. or:
>> FID=<int> - or: FID of file.
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> SIZE=<int> - The size of the file.
>> MSG=<str> - Command return message. (Only final message
unless you issue LOG)
[ Example ]
>> SIZE|SID=1|PATH=giana2k.xm.zip
<< SIZE|SID=1|CODE=0|SIZE=287688|MSG=213 287688
DELE
Delete a single file on the remote server. You can either issue by
name (relative path, or absolute path), or optionally use FID as
returned by DIRLIST.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
>> PATH=<str> - Name of File. or:
>> FID=<int> - or: FID of file.
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message. (Only final message
unless you issue LOG)
[ Example ]
>> DELE|SID=1|PATH=delete_this.bin
<< DELE|SID=1|CODE=0|MSG=213 DELE command successful.
MKD
Create a new directory on the remote server.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
>> PATH=<str> - Name of Directory.
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message. (Only final message
unless you issue LOG)
Delete a single directory on the remote server. You can either issue by
name (relative path, or absolute path), or optionally use FID as
returned by DIRLIST.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
>> PATH=<str> - Name of Directory. or:
>> FID=<int> - or: FID of directory.
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message. (Only final message
unless you issue LOG)
[ Example ]
>> RMD|SID=1|PATH=delete_this_dir
<< RMD|SID=1|CODE=0|MSG=213 RMD command successful.
SITE
Send a SITE command to the remote server.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
>> CMD=<str> - Command and arguments to send.
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message. (Only final message
unless you issue LOG)
[ Example ]
>> SITE|SID=1|CMD=WHO
<< SITE|SID=1|CODE=0|MSG=200 Command Successful.
REN
Rename a file or directory. Supply the originating name by either
passing FROM or a valid FID, as well as the resulting TO name.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
>> FROM=<str> - Source name. or:
>> FID=<int> - or: FID of entry.
>> TO=<str> - Destination name.
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message. (Only final message
unless you issue LOG)
[ Example ]
>> REN|SID=1|FROM=oldfilename.bin|TO=newfilename.bin
<< REN|SID=1|CODE=0|MSG=250 RNTO command successful.
MDTM
Return the date and time of a file. (But not directories, according to
FTP RFC). The return data is in the format of yyyyMMddHHmmSS. For
example, "213 19970205115719". You can either issue by name (relative
path, or absolute path), or optionally use FID as returned by DIRLIST.
[ Minimal Required Fields]
>> SID=<int> - SID of the session
>> PATH=<str> - Name of Directory. or:
>> FID=<int> - or: FID of directory.
[ Optional Arguments ]
>> LOG - Send all strings with command, like SESSIONNEW
[ Returns ]
>> SID=<int> - SID of the session
>> CODE=<int> - Command return status CODE.
>> MSG=<str> - Command return message. (Only final message
unless you issue LOG)
[ Example ]
>> MDTM|SID=1|PATH=somefile.bin
<< MDTM|SID=1|CODE=0|MSG=213 19970205115719
QUEUES
QUEUENEW
Create a new QUEUE by associating two SIDs with it. These are
currently named NORTH and SOUTH as a means to refer to either one
uniquely without implying direction of transfer. (source and
destination does not work)
[ Minimal Required Fields]
>> NORTH_SID=<int> - SID of the session, out of two.
>> SOUTH_SID=<int> - SID of the session, out of two.
[ Optional Arguments ]
[ Returns ]
>> QID=<int> - Queue ID for queue operations.
[ Example ]
>> queuenew|north_sid=1|south_sid=2
<< QUEUENEW|CODE=0|QID=1|MSG=Queue created.
QADD
Add a new items to a specified queue. This is quite a versatile
command which looks to take many arguments. As a command it has four
parts to it. Except for special QTYPE values, see below.
The source information. The easiest way here is to use the FID option, if you have previously done a DIRLIST command. This will take the required source information from the directory cache. If FID is not used, or you wish to override information from the FID, you can specify the source information manually. The name of the item can either be specified by SRCDIR+SRCNAME OR SRCPATH. (SRCPATH = SRCDIR/SRCNAME). The extra SRC options, like SRCSIZE, and SRCREST are optional. Both are used for Resume purposes, as well as finally CPS calculations.
The destination information. This is copied from the source. However, you can optionally override any of this. For example specifying a different DSTNAME would transfer and rename the file at the same time. The PATH is made up the same way as source, specify one of the two in: (DSTPATH = DSTDIR/DSTNAME)
Queue position. This can be omitted for default queue positioning. However if the specific position is desired, you can use @=<int|FIRST|LAST> to specify Nth position, FIRST position or LAST position in the queue.
Optional modifiers. The default behaviour of a SITE is to always RESUME unless specified otherwise using the "resume" option to the site definition. The default for a queue item is also to resume. You can override this default for THIS queue item by specifying "OVERWRITE" or "RESUME". The latter is useful if the site's default has been changed to OVERWRITE. You can also specify QTYPE for this addition, either due to manual queuing, or to override the FID type. If you get it wrong, the queue processing will also get it wrong.
Alternatively, you can use QTYPE to set non transfer type items. At
this time, there is only type "STOP". If you issue QTYPE=STOP there is
no need to send information for 1), 2) or 4). Part 3) is optional.
There is currently a bug where you have to specify SRC= field with the
STOP item. It makes no difference as to which SRC you pick.
[ Minimal Required Fields]
>> QID=<int> - Queue ID
>> SRC=<str> - Specify which SID is the source. Either "NORTH"
or "SOUTH".
EITHER:
>> FID=<int> - File ID to use as source
OR:
>> SRCPATH=<str> - Full path of the source file
OR:
>> SRCNAME=<str> - Name of source file.
>> SRCDIR=<str> - Directory path containing source file.
OR:
>> QTYPE=STOP - Insert a soft stop item
[ Optional Arguments ]
>> SRCNAME=<str> - Name of source file
>> SRCDIR=<str> - Directory path containing source file
>> SRCPATH=<str> - Full path, ie, SRCDIR/SRCNAME in one.
>> SRCSIZE=<int> - Size of the queue item.
>> SRCREST=<int> - Restart point of queue item (files only).
>> DSTNAME=<str> - Name of destination file, OR obtained from source
>> DSTDIR=<str> - Directory path containing destination file, OR
obtained from source
>> DSTPATH=<str> - Full path, ie, DSTDIR/DSTNAME in one. OR
obtained from source.
>> DSTSIZE=<int> - Size of the queue item.
>> DSTREST=<int> - Restart point of queue item (files only).
>> QTYPE=<str> - Type of queue item. Either "directory",
"file" or "stop". [1]
>> RESUME - Resume file if possible.
>> OVERWRITE - Do not resume, overwrite destination
>> @=<int|str> - Queue position, int or FIRST/LAST strings.
[1] More types will come. The default type is "file".
[ Returns ]
>> QID=<int> - Queue ID
>> CODE=<int> - Command return status CODE.
>> ITEMS=<int> - Number of items in the queue
>> MSG=<str> - Command return message.
>> @=<int> - Position in the queue item was inserted.
>> SRCPATH=<str> - Original source path used (to identify QADD reply, and use "@")
>> DSTPATH=<str> - Original destination path used (to identify QADD reply, and use "@")
>> FID=<int> - If QADD was called with FID=, the QADD reply will also contain FID.
What is the default queue position when QADD is called, or during file
transfers? When the API queues items, they will always be placed LAST
unless otherwise specified.
As a default, files are added after all the (top) files, but before
the first directory. Directories are added after all files, but before
the first directory. (yes, it's the same). Which the exception of if
the name matches "fmovefirst" or "dmovefirst", then it is inserted
with "FIRST" position.
This means, when it is expanding a directory, the queue ends up like:
FIRST
files that match fmovefirst
all other files
directories.
LAST
QLIST
List all queues on the engine, and their current states.
[ Minimal Required Fields]
[ Optional Arguments ]
[ Returns ]
>> QID=<int> - Queue ID
>> NORTH=<str> - Name of the North site
>> SOUTH=<str> - Name of the South site
>> ITEMS=<int> - Number of queue items
>> STATUS=<str> - Current processing state
>> ERRORS=<int> - Number of items in the error queue.
>> KB/s=<int> - Transfer speed of last completed transfer.
>> SUBSCRIBED - Sent if client is subscribed to events from this queue.
>> BEGIN - First item sent, start of list.
>> END - Final item was sent, end of list.
Get the contents of a specific queue, all its queue items.
[ Minimal Required Fields]
>> QID=<int> - Queue ID
[ Optional Arguments ]
[ Returns ]
>> QID=<int> - Queue ID
>> @=<int> - Position in the queue of item.
>> FTYPE=<str> - Item type, directory/file.
>> SRC=<str> - Source SID is "NORTH" or "SOUTH".
>> SRCPATH=<str> - Full path of source
>> SRCSIZE=<int> - Source size, if known.
>> SRCREST=<int> - Source restart point.
>> DSTPATH=<str> - Full path of destination
>> DSTSIZE=<int> - Destination size, if known.
>> DSTREST=<int> - Destination restart point.
>> ITEMS=<int> - Number of items in the list.
>> BEGIN - First item sent, start of list.
>> END - Final item was sent, end of list.
Get the contents of a specific error queue, all its queue items.
[ Minimal Required Fields]
>> QID=<int> - Queue ID
[ Optional Arguments ]
[ Returns ]
>> QID=<int> - Queue ID
>> QTYPE=<str> - Item type, directory/file.
>> SRC=<NORTH|SOUTH>- This item's source site is North or South.
>> SRCPATH=<str> - Full path of source
>> DSTPATH=<str> - Full path of destination
>> SERR_<int>=<str> - Source errors, incrementing, and the reason string
>> DERR_<int>=<str> - Destination errors, incrementing, and the reason string
>> BEGIN - First item sent, start of list.
>> END - Final item was sent, end of list.
[ Example ]
>> QERR|QID=1|BEGIN|ITEMS=1
<< QERR|QID=1|QTYPE=FILE|SRC=NORTH|SRCPATH=/Giana_Sisters_GBA//gfx_blocks.txt|DSTPATH=/tmp/tmp//gfx_blocks.txt|DERR_0=553 gfx_blocks.txt: Can't open for writing
<< QERR|QID=1|END
QDEL
Delete an item in the queue. If a client wishes to delete multiple
items, it is advised that the client pre-sorts the items list, and
send it with highest queue position first, in descending order. It is
an error to attempt to delete queue item at first position (@=0) if
the queue is active.
Please be aware that since deleting a queue item early in the list,
will affect queue items in a later position. That is to say, if you
intend to delete items 1,4,8 from the queue, and you issue 3 QDEL
commands "blindly" in the same order (1,4,8), the net effect will be
that queue items 1,5,10 are actually deleted. When queue item 1 is
deleted, item at position 4 is now 3, and item 5 is at position 4.
Either the clients need to be aware of the re-numbering and compensate
for later commands,
OR,
much easier is to sort the list in descending order before issuing the
QDEL commands. Ie, send QDEL commands in the order 8,4,1.
[ Minimal Required Fields]
>> QID=<int> - Queue ID
>> @=<int> - Queue position of item to delete.
[ Optional Arguments ]
[ Returns ]
>> QID=<int> - Queue ID
>> CODE=<int> - Command return status CODE.
>> ITEMS=<int> - Number of items in the queue
>> MSG=<str> - Command return message.
>> @=<int> - Position in the queue of item.
[ Example ]
>> qdel|qid=1|@=53
<< QDEL|QID=1|CODE=0|@=53|ITEMS=0
QMOVE
Move an item in the queue from one position to a new position. It is
an error to move a queue item from, or to, the first position (@=0)
when a queue is active.
[ Minimal Required Fields]
>> QID=<int> - Queue ID
>> FROM=<int> - Queue position of item to move
>> TO=<str|int> - New position, either <int> Nth place, or string
placement like in QADD. ("FIRST"/"LAST")
[ Optional Arguments ]
[ Returns ]
>> QID=<int> - Queue ID
>> CODE=<int> - Command return status CODE.
>> ITEMS=<int> - Number of items in the queue
>> MSG=<str> - Command return message.
>> @=<int> - Position where item was inserted.
>> FROM=<int> - Position where item was originally from.
[ Example ]
>> qmove|qid=1|from=0|to=last
<< QMOVE|QID=1|@=23|FROM=0|CODE=0|ITEMS=3|MSG=Moved
QGRAB
QGRAB lets a client take control of an idle queue, and the queue's
sessions, if any. This is currently the only way to gain access to
sessions given away with the "GO" command. If the queue had any
connected sessions, the client should receive appropriate CONNECT
messages.
[ Minimal Required Fields]
>> QID=<int> - Queue id in question
[ Optional Arguments ]
[ Returns ]
>> QID=<int> - Queue id
>> ITEMS=<int> - Current number of items in queue
>> NORTH_SID=<int> - Session ID of North site, if connected.
>> SOUTH_SID=<int> - Session ID of South site, if connected.
>> NORTH_SITEID=int - Site ID of North site, for future SESSIONNEW
>> SOUTH_SITEID=int - Site ID of South site, for future SESSIONNEW
>> NORTH_NAME=<str> - Site name of North site
>> SOUTH_NAME=<str> - Site name of South site
>> CODE=<int> - Command return status CODE.
Compare the two directories in the session cache against each other,
sending back list of FIDs that would be queued by FXP.One. This gives
GUIs an easy way to show which items would be queued, and processed in
a given set of directories. The compare function uses all the logic,
including skiplists, passlists, movefirst and skipempty. It compares
file sizes to ignore those of the same size, but highlights the side
with the smaller size should they differ.
[ Minimal Required Fields]
>> QID=<int> - Queue ID
[ Optional Arguments ]
[ Returns ]
>> QID=<int> - Queue ID
>> NORTH_FID=<int,> - Comma separated list of FIDs for the NORTH site.
>> SOUTH_FID=<int,> - Comma separated list of FIDs for the NORTH site.
>> BEGIN - First item sent, start of list.
>> END - Final item was sent, end of list.
[ Example ]
>> QUEUEFREE|QID=1
<< QUEUEFREE|CODE=0|QID=1|Msg=Queue released.
GO
Issue "GO" to a queue. Request FXP.One engine to start processing the
queue and its items. The client loses ownership of the two SIDS at the
issue of the "GO" command. You may no longer issue commands directory
to the SIDs. Once a queue is idle, either from the QC|EMPTY message,
or after issuing the STOP command, the client can issue the "QGRAB"
command to receive controls of the SIDs, if still existing.
[ Minimal Required Fields]
>> QID=<int> - Queue ID
[ Optional Arguments ]
>> SUBSCRIBE - Subscribe to queue status (QS) and queue changes (QC)
[ Returns ]
>> QID=<int> - Queue ID
>> CODE=<int> - Command return status CODE if failed.
>> MSG=<str> - Command return message.
[ Example ]
>> GO|QID=1
<< GO|QID=1|CODE=0|MSG=Queue processing started.
STOP
Issue "STOP" to a queue. Request FXP.One engine to attempt to stop processing the
queue and its items. There are currently three types on STOP levels, the default is
"SOFT", which will stop once the current transfer is complete. "HARD" which will attempt to send the FTP command 'ABOR' to both FTPDs to gracefully interrupt the current transfer. (local client might need ABOR support added) Finally, the "DROP" method which will log out of both FTPDs and hence forcing the transfer to stop. Once the queue processing has stopped, the FXP.One engine will issue a "QC|IDLE" command, after which the client can issue QGRAB.
[ Minimal Required Fields]
>> QID=<int> - Queue ID
[ Optional Arguments ]
>> HARD - Send FTP 'ABOR' to FTP daemons
>> DROP - Drop connections to FTP daemons to cancel transfers.
[ Returns ]
>> QID=<int> - Queue ID
>> CODE=<int> - Command return status CODE if failed.
>> MSG=<str> - Command return message.
This is a receive-only command, sent by the FXP.One engine when there
is a Queue-Change. It is only sent if the client requested to
SUBSCRIBE to a queue, either using the "GO" command, or the "QGET"
[ Minimal Required Fields]
[ Optional Arguments ]
[ Returns ]
>> MOVE - Item has moved to a new position. Comes with
FROM= and TO= keys.
>> REMOVE - Remove items from queue. All items with higher
position are decremented by one. Uses @.
>> INSERT - New item inserted into queue. Uses @, SRCPATH,
DSTPATH, QTYPE, SRCSIZE.
>> EMPTY - Empty queue, processing stops.
>> IDLE - Queue moved into IDLE state, either from QTYPE=STOP or
in response to a STOP command.
[ Example ]
<< QC|QID=1|REMOVE|@=0
<< QC|QID=1|MOVE|FROM=0|TO=18
<< QC|QID=1|INSERT|@=0|SRCPATH=/testfile.dat|DSTPATH=/tmp/testing.bin|QTYPE=FILE|SRCSIZE=29734
When the FXP.One is expanding a directory, it may send a large amount of QC|INSERT items to the clients,
so in an attempt to assist clients to avoid frequent display refreshing, the engine will add the tag |EXPANDING to some items, and
follow with a QS|REFRESH command to indicate the directory expansion has completed. It is considered an optimisation and can
be ignored.
QS
This is a receive-only command, sent by the FXP.One engine when there
is Queue-Status information to relay. Client can safely ignore this
command as it does not reflect on any queue changes. It is merely
meant as a way for clients to be able to track progress of a queue
being processed. It is only sent if the client requested to
SUBSCRIBE to a queue, either using the "GO" command, or the "QGET"
(Not yet implemented).
All QS messages are related to the item at the top of the queue. So
"@=0" is implied.
[ Minimal Required Fields]
[ Optional Arguments ]
[ Returns ]
>> START - Started processing the item at the top of queue.
SRCPATH=<str> - Included for human readability.
>> SRCCWD=<str> - Changed to new directory on source
>> DSTCWD=<str> - Changed to new directory on destination
>> MKD=<str> - Created new directory on destination
>> XFRACT - File transfer has started (received 150)
SECURE=<yes/no>- Was Secure Data negotiations successful.
REST=<int> - Are we resuming this file
SIZE=<int> - Final source size (from SIZE command)
>> XFREND - File transfer finished (successfully, 226).
TIME=<int> - Duration of transfer [1]
KB/s=<int> - Estimated speed of transfer [1]
>> FAILED - Attempted transfer failed
SERR=<str> - Error reasons (source failed)
DERR=<str> - Error reasons (destination failed)
COUNT=<int> - This failure count.
[1] Please be aware that we can only measure the time difference
between the 150 FTP message, and the 226 FTP message as received by
FXP.One. This may not reflect the actual time taken for the transfer,
subsequently the KB/s computation is based on said time, and will most
likely only be an estimate. The shorter the duration of a file
transfer is, the more inaccurate the speed computation will be.
Request to receive the QS and QC commands from a processing queue. A
client may subscribe to as many queues as it wants, including those
not started by itself.
[ Minimal Required Fields]
>> QID=<int> - Queue ID
[ Example ]
>> UNSUBSCRIBE|QID=1
<< UNSUBSCRIBE|QID=1|CODE=0|MSG=Unsubscribed
QCLONE (v1.7)
Take a created queue (idle or active) and make an exact copy of the queue. If source queue is active, connect both sides and start processing. Some clients refer to this as "add another thread".
[ Minimal Required Fields]
>> QID=<int> - Queue ID
[ Optional Arguments ]
>> START=<yna> - Start processing (Y), do not start processing (N), or copy source (A). Default is (A).
>> SUBSCRIBE - Also subscribe to queue processing notices.
[ Returns ]
>> QID=<int> - Source Queue ID, same as given.
>> NEWQID=<int> - Newly created clone Queue ID
>> MSG=<str> - Command return message.
[ Example ]
>> QCLONE|QID=123
<< QCLONE|QID=123|NEWQID=124|CODE=0|MSG=Queue 124 processing started.
In reality, it is a little more verbose, here is an actual example:
>> QCLONE|QID=1
<< SESSIONNEW|SITEID=15|CODE=0|SID=3
<< SESSIONNEW|SITEID=16|CODE=0|SID=4
<< QUEUENEW|CODE=0|QID=2|NORTH_SID=3|SOUTH_SID=4|MSG=Queue created.
<< QCLONE|CODE=0|QID=1|NEW_QID=2|Msg=Cloned and created queue
<< CONNECT|SID=3|SSL
<< IDLE|SID=3
<< CONNECT|SID=4|SSL
<< IDLE|SID=4
<< GO|QID=2|CODE=0|MSG=Queue processing started.
ADMINISTRATIVE COMMANDS
QUIT
Disconnect from the FXP.One engine. The client can also just close the connection without worry.
[ Minimal Required Fields]
[ Optional Arguments ]
[ Returns ]
>> Will disconnect on you, how rude.
[ Example ]
>> QUIT
<< Connection closed by remote host.
HELP
Display available commands at this privilege level.
[ Example ]
>> HELP
<< HELP|CODE=0|Msg= QUIT HELP WHO SHUTDOWN SITEADD SITELIST SITEMOD SITEDEL SESSIONNEW SESSIONFREE
DIRLIST QUEUENEW QADD QLIST QGET QERR QGRAB QDEL QMOVE QCOMPARE QUEUEFREE GO STOP CWD PWD
SIZE DELE MKD RMD SITE REN MDTM QUOTE SUBSCRIBE UNSUBSCRIBE.
WHO
Display a list of users connected to this FXP.One engine.
[ Minimal Required Fields]
[ Optional Arguments ]
[ Returns ]
>> NAME=<str> - User name of login session
>> HOST=<ip> - IP address of login session
>> PORT=<port> - Remote port number
>> SSL=<yes|no> - Is connection encrypted
>> CLIENTS=<int> - Number of items in the queue
>> BEGIN - First item sent, start of list.
>> END - Final item was sent, end of list.
[ Example ]
>> WHO
<< WHO|BEGIN|CLIENTS=3
<< WHO|NAME=admin|HOST=127.0.0.1|PORT=58597|SSL=yes
<< WHO|NAME=admin|HOST=220.150.239.57|PORT=1135|SSL=yes
<< WHO|NAME=admin|HOST=127.0.0.1|PORT=58540|SSL=no
<< WHO|END|Msg=Command Completed.
SETPASS
Change the login password on the FXP.One engine. This is strongly encouraged.
[ Minimal Required Fields]
>> OLD=<str> - Old/current password of this login session.
>> NEW=<str> - New/future password for this login session.