For recap for others, when you view articles in the melkjug ui, there
is basically a little chatter that goes back and forth like:
-> POST /some/jug/mash {some filter configuration, etc.} (pick articles)
<- list of article ids ['melk:239472983472', ...]
-> POST /some/jug/article_html (post list of desired article ids)
<- json dictionary {'melk:239472983472': <article html>, ...}
This is not particularly RESTful and it does rely on the javascript UI
knowing quite a bit about the URL structure of the API.
On Mar 12, 2009, at 6:02 PM, Randall Leeds wrote:
After reading this a blog post by Ian, I was thinking about how it
would apply to Melkjug.
In request for /mash returns a list of melk ids, such as "melk:
2da0ee77-0f08-17ac-8128-f63babdcd16e"
I'm wondering if the following makes me sense and could give a
performance boost in the future:
Send back a list of URLs instead of melk ids, or probably a list of
tuples with (url, metadata ...). The url would essentially be the
melkid placed under some root article url path.
We could certainly to something more like:
-> POST /some/jug/mash {some filter configuration etc.} (pick articles)
<- list of article URLs ['/articles/melk:239472983472', ]
-> GET /articles/melk:239472983472 [just article content]
-> GET /articles/...
...
This is much more sane and easy for cache's to take care of which Josh
has brought up before.
For one, this means we don't need to transfer article html in the
collapsed view until an item is expanded. In the case of the
expanded view it means more client requests, but a load balancing
proxy or other such client request entry point could bypass our app
altogether and proxy a local request to CouchDB directly. Please
weigh in here, because I'm not sure my thinking is correct, but I
think this could give us caching advantages at the proxy point.
I agree we could use this to defer loading the actual content until
expansion. If we structured it to be so, I'm sure we could handle
some basic portions of the API like article content directly with
CouchDB. Whether there is something paired with it to do some extra
processing or not, I think the basic point of using load balancing
proxies to divide and conquer this sort of work is legit.
The one concern I have is that article_html is supposed to be
returning pretty serious html formatting around the article content.
I don't know if there's a way to use CouchDB api to allow an
external formatter (and if this partially negates the benefits
described above) like a JSON analogue of XSLT.
In any case, exposing the raw json of an arbitrary article from the
couch (possibly in addition to an html-formatted view) seems to fit
nicely into the notion of melkjug-as-service.
I feel like the reader frontend should be adjusted to make the
metadata and dynamic bits (essentially the wrapper around the article
content containing widgets and metadata) a separate API call that is
reader-centric. I feel like I'd want the article id more than the
URL pointing to it's content again in this case though. I'm not sure
how to structure related calls in an application using this API... I
guess I could probably be considering the id of the thing to be '/
articles/melk:23840923849082' instead of 'melk:3024892340923' in the
reader gui.
Also it's worth nothing that what we might consider to be melkjug API
at this point needs to be teased apart conceptually into the
melkjug.org web gui's api and the more general purpose API that
supports other clients / ways of rendering articles etc. There will be
at least some in both categories. The unofficial documentation of
google reader is an interesting example of doing this.
- Luke
