It was cool to play ultimate, wasn't it? I'm looking forward to play again, unfortunately my disc is getting dusty since I left Galway :( but this summer I want to set up a team and play! Definitely!
I'll probably come over to Innsbruck in April, I'll bring it so we may play! :)
]]>Looking forward to seeing you.
]]>Pictures and videos still make sense by directory to me though.
Maybe files by tagging will take over selected directories like music.
]]>Juergen
[1]http://prashblog.com/files/hipaac.pdf
[2]http://www.tagsistant.net/
And yet, if we don't seize opportunities to put the technologies we are working on into practice, how shall we escape the charge that what we are saying to others is, in effect, "Do as I say, not as I do"?
When we began work on the Text Encoding Initiative, a large project to develop an SGML (now XML) vocabulary for use by scholars in the humanities, I suggested that all internal documents be written in SGML, preferably in an approximation of the tag set we were defining. Lou Burnard, my co-editor, argued that this was crazy, since (a) the TEI Guidelines were primarily intended for representing pre-existing documents, not for document production, and (b) we didn't have any software to produce documents using SGML. He wanted to use LaTeX instead. From a project-management point of view, perhaps he was right: we might have been finished faster if we had used LaTeX instead of struggling to refine our tag set and develop our tools at the same time as writing the Guidelines. But I think the Guidelines are a lot better for having been edited with the understanding of markup in practice that we got by insisting on using SGML ourselves.
It's not clear whether I am disagreeing with you or not. In practice, I don't always do what I'm preaching here: I continued to use SGML for most of my documents until well after XML became a recommendation, since I had a well-working SGML tool chain, and did not switch to pure XML until ... well, a lot later than some of my colleagues.
Then there was the proposal that the chairs make it a requirement for membership in the [name redacted] Working Group that each member submit, every six months, a working example they had written of a [name redacted] using the current draft spec, to show that they knew how to use the technology they were specifying. I can think of Working Groups which would have been much less crowded if that test had been applied.
]]>Using our own technologies as we develop them would generally make them better, I agree wholeheartedly. Instituting requirements along these lines in standardization bodies would be an intriguing experiment, but in such a political setting, it might be dropped on a technicality.
But criticizing others for not using their own technologies should be done after careful consideration. But then, I'd like all criticism to be done after careful consideration, so I guess there's nothing new here...
]]>1) Application and resource state live on the server, in the database/content of the Web App, e.g. products, prices, delivery status on Amazon, pictures on Flickr.
2) User state mostly lives on the server, e.g. user preferences, stored personal info, stuff such as wish-list on Amazon, friends on Flickr.
3) Session state would then be the state of a fairly short-lived complex interaction between the client and the server, e.g. a shopping basket on Amazon, position on a map in Google maps, and the "current" user ID manywhere.
Resource state is a part of application state as I see it, but it should not be touched by session state. There are reasons why parts of the session could be on the server, but then it should become resources.
]]>Sorry - that was a typo on my blog. It should have been "HATEOAS" or Hypermedia As The Engine Of Application State.
Jim
]]>