Hello Jeremy, First of all, thank you for taking the time to analyze TiddlyDrive.
> > It's looking great, well done. I did some experimentation but the server > seems to have stopped responding. I'm now seeing the POST to > "exec/action=listTiddlers" stuck in the (pending) status, with no response > from the server. Apologies if I crashed it. > It is working for me. > > I did notice a few things (you may have mentioned them in earlier threads, > I'm afraid I'm in the process of catching up on the groups) > > When loading a server tiddler the "created" and "modified" fields are > coming through as "NaNNaNNaNNaNNaNNaNNaN". I suspect that you're passing a > string for those fields that is not in the YYYYMMDDhhmmssmmm format > expected by the core (eg "20141208203732926") > > Yes, I noticed it. I find that the core also works with date objects. So if I create a date like this new Date(my-no-TW-valid-date) and I put it in any of the date fields it works. This is just a patch and I'm on the way to properly save tiddlers. > An architectural concern is that you're using an HTTP POST request to > retrieve data from the server. Strictly, that is not correct. HTTP verbs > like GET and POST have specific semantics. > I know. The reason I'm using get instead of post is because the httpRequest of the core (inside utils) does not encode postData if I make a GET request. This is not correct neither because a GET request can have post data. > The idea is that a URL represents a resource - a thing that you can do > things to. POSTing to a resource is intended to create a new subordinate > resource. There's a good summary in Wikipedia: > > http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods > > This topic is also referred to as "REST"; you'll find lots of articles > explaining why POSTing to retrieve data is a bad idea. This one seems > reasonable: > > http://blog.teamtreehouse.com/the-definitive-guide-to-get-vs-post > > I have a GET vs POST article also in my personal wiki. I though several times in creating a REST service for tiddlers, but there are two issues I have to face: - It is more complicated to implement. - I can not specify what I already have. Currently I make a post to the server telling what I have already, and the server answers back with what I do not have. I make it this way for performance, but maybe it does not deserve the effort. > All of this might seem very arcane, but I've found that it's worth trying > to get it right. You'll end up with something more reliable and with better > performance. > That's what standards are for, right? I should stick to them. > > A more basic concern is that as we've discussed before, what you've got > here is doing the same job as the tiddlyweb adaptor in the TiddlyWiki core. > Very similar but not the same at all. > These are called "skinny tiddlers". Click open a link to, say, "close.svg" > in the "Recent" tab and you should see a brief flicker as another GET > request is fired to retrieve the full tiddler, including the text field. > This process is called lazy loading; wiki.js implements a convention > whereby if the text field of a tiddler is requested and that tiddler lacks > a text field, then via an event the syncer module is given the opportunity > to load the named tiddler. > Hello. I have been studying skinny tiddlers for a while, and there are some mysterious parts to me. I know that a tiddler without text is considered a skinny tiddler, but there is no way to reference a skinny tiddler or give it a special viewTemplate while it is not "fat". I created a space and I can see that most of the server responses are "instantaneous". Maybe this is one of the advantages of REST, it can be cached. I can see that a skinny tiddler is retrieved as a response of a "lazyload" event. I expected a tm-lazyload event instead. Anyway, seems there is no other way to load skinny tiddlers. > > If you try to create a tiddler you'll get a 403 error because you're not > authenticated, but you should be able to see the HTTP PUT request that is > issued to create the tiddler. "PUT" is used to create a resource if the > name is known by the client, while "POST" is used if the server must > allocate a name to the new resource. > So creating tiddlers should be always a put request? > > Listing the problems might all sound very discouraging, but it's not > intended to be. > Actually I was aware of many of them. You are only confirming my suspects. > You'll have learned a great deal in getting as far as you have, and > possibly now be in a much better position to start to see why the tiddlyweb > is architected as it is. > Yes, but still A LOT to learn. > And of course, you have adopted goals that are more ambitious than the > current incarnation of the tiddlyweb adaptor. > That was not my intention. I just wanted a way to save tiddlers to my google drive when all this started and avoid dropbox for syncing the whole html file. > Anyhow, I think it might be worth having a look at the TiddlyWeb adaptor > to see if you can pick up some techniques that will simplify your plugin. > I did several times, and of course I will look at it again. > If you're around for the hangout tomorrow perhaps we can devote some time > to looking at the code then? > <javascript:> > That will be lovely. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywiki. For more options, visit https://groups.google.com/d/optout.
