Camelia, the Perl 6 bug

IRC log for #kaizendo, 2010-10-26

| Channels | #kaizendo index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:34 Github-sjn joined #kaizendo
00:34 Github-sjn Kaizendo: master Salve J. Nilsen * f9701c7 (1 files in 1 dirs): C:A:REST 0.86 has support for json_options
00:34 Github-sjn Kaizendo: master Salve J. Nilsen * b3fd39a (3 files in 2 dirs): Merge remote branch 'origin/master' into comments-01
00:34 Github-sjn Kaizendo: master Salve J. Nilsen * cd8608c (4 files in 3 dirs): Add Sveinn's chapters to test suite
00:34 Github-sjn Kaizendo: master Salve J. Nilsen * 35a4b96 (1 files in 1 dirs): Temporarily store C:A:REST patch ...
00:34 Github-sjn Kaizendo: master Salve J. Nilsen * c59e32b (1 files in 1 dirs): Add example for comment list structure
00:34 Github-sjn Kaizendo: master Salve J. Nilsen * e106ef8 (21 files in 4 dirs): Just generate the content div, nothing above body ...
00:34 Github-sjn Kaizendo: master Salve J. Nilsen * f7f70a5 (19 files in 3 dirs): Use proper HTML entities in the example book
00:34 Github-sjn Kaizendo: master commits 5d4a37c...f7f70a5 - http://bit.ly/bO5DYK
00:34 Github-sjn left #kaizendo
00:54 sjn hmf
00:54 sjn forgot to remove some stuff from there
00:59 sjn at least the content looks better now
01:00 sjn <- Zz
05:10 dreadnact_ joined #kaizendo
05:19 dreadnact_ left #kaizendo
05:32 dreadnact_ joined #kaizendo
07:03 sjn dreadnact_: one question... what was the purpose of having a #text_content div in addition/instead of one just tagged with #content?
07:05 sjn you said something about "content can be other things than text", but I don't see that :-/
07:06 sjn (this is maybe one of those "so what" issues... it just bugs me a little since I'm one of those that like simplicity everywhere...)
07:13 dreadnact_ left #kaizendo
07:53 dreadnact joined #kaizendo
07:54 dreadnact #text_content is the container for the text that can be commented on
07:55 dreadnact #content is the container for the middle column
07:55 dreadnact they serve different purposes
07:56 dreadnact since you may want to put content other than the contents of a book in the middle column
07:56 dreadnact there is also a technical reason to do with positioning the highlighted text under the original text
07:58 dreadnact to be honest there is a lot of cleanup to do on the html, for a start we should be using html5 tags, like header,footer,section and nav
08:05 sjn I agree :)
08:05 sjn sveinns: (hint, hint ;)
08:06 * sjn is uncharacteristically early up today
08:06 sjn after a mere 6h sleep
08:07 dreadnact This is a good reference for all the new tags you can use: http://www.w3schools.com/html5/html5_reference.asp
08:09 dreadnact I was intending to take a look at cleaning it up myself, since I was adding gunk anyway for the commenting system, the only thing was I have only used bluprint in the context of compass, which means I have been putting off
08:10 dreadnact who made the html/css, more specifically chose bluprint
08:10 dreadnact At some point I would like to introduce the person in question to compass
08:12 * sjn is the guilty one :)
08:13 sjn do you have an url?
08:14 sjn hm
08:14 sjn compass-style.org
08:17 sjn dreadnact: well, if you're up for making something with compass/sass, then feel free to make a branch :)
08:17 dreadnact finding the video I watched
08:18 * sjn likes the sass syntax (have always missed that in CSS) but I'm not a big fan of introducing new stuff.
08:18 dreadnact but yes I may just branch, but would be useful for you to understand the basics
08:18 sjn the reason I put in blueprint was that it had a reproducable css generation step
08:19 sjn no idea if that's the case with compass. if it is, then I'm fine with replacing blueprint with it :)
08:20 dreadnact ok found it: http://vimeo.com/4335944
08:20 dreadnact its a bit old
08:20 sjn (and with "reproducable css generation step" i mean a single command that generates valid CSS from .sass source files
08:20 dreadnact but its the best video to get an idea of how to use bluprint
08:20 sjn )
08:21 dreadnact the intro video on the main site is a bit short
08:21 dreadnact but if you have an hour its worth watching
08:21 dreadnact the other video that is
08:21 sjn I'll look into that later :)
08:22 * sjn has a presentation about Kaizendo in Bergen on thursday, so I'd like to have some backend stuff ready by then :)
08:23 sjn dreadnact: I'd love it if you could look at the files in root/sandbox and edit them so that they represent what you'd like to see from the server
08:24 dreadnact ah, I was going to ask
08:24 dreadnact how are you expecting to shpw child comments
08:24 sjn the comment_list.yml file is pretty close (although it doesn't have the structure you're working with now)
08:24 sjn show?
08:24 dreadnact s/shpw/show
08:24 sjn as in the webpage, or as in transfer them in a JSON stream?
08:25 dreadnact json stream
08:25 sjn good question :)
08:25 sjn my initial idea is this....
08:26 sjn 1) request id's, locations and subject/authors using a .../_c/ URL
08:26 sjn 2) when someone clicks on a field, get the corresponding discussions from the server using a .../_c/$id URL
08:27 sjn field=selected content
08:27 sjn gah, need to get that glossary up
08:27 sjn 3) the discussions (as of now) I thought should be a nested hash
08:28 sjn not sure about that. maybe it's easier to just flatten it, and use id's in each comment to represent parent/chrildren?
08:29 sjn dreadnact: I think you should decide, really... what's the easiest to implement?
08:29 sjn recursively going through a pre-generated thread, or building a thread from a flat list of id's?
08:29 dreadnact Have you seen the latest version of commentSelection.js
08:30 dreadnact the comments are nested in a field called "comments"
08:30 sjn I haven't
08:31 dreadnact that would be fine, but then you need some system of defining what fields you want back when you make a request
08:31 dreadnact something like an object_property_filter
08:31 dreadnact am I making any sense
08:31 dreadnact ?
08:32 sjn why do you have to define what fields to get back?
08:32 dreadnact because in some cases you may not want a field which is very large
08:33 dreadnact ie, containes 300 child comments
08:33 sjn ah
08:33 sjn that's trivial
08:33 dreadnact if you only intend to show the single comment
08:33 dreadnact but you need a consistant method of defining which fields to return
08:34 sjn .../_c/id_of_long_thread?comments=50&offset=0
08:34 dreadnact theres also the possibility of asking for a perticuler field to be in a specific format
08:34 dreadnact but generally that stuff bites you when you start caching
08:35 sjn that last one, I'm not so sure about that (what's the use case for that?)
08:35 dreadnact I more a fan of fields generates on the fly
08:35 dreadnact asking for a date to be in a specific format
08:35 dreadnact or timezone
08:35 dreadnact or filesize
08:36 sjn ok, and what's the use case?
08:36 dreadnact in france they have a different name of unit for filesize
08:36 dreadnact ok, a client asks for the list of comments in JSON through the REST API
08:36 sjn hm
08:37 dreadnact its a flash client
08:37 sjn if we're giving bytes, do we really have to think formatting? (can't that be handled by the client?)
08:37 dreadnact it wants to put the dates in a specific format that is readable across a timeline
08:38 dreadnact which is how it shows the history or a discussion
08:38 sjn right
08:38 dreadnact but flash has really bad date formatting tools
08:38 dreadnact where perl is really easy to parse dates
08:39 sjn ok, I see your point, but I think that's something that can wait
08:39 dreadnact yes, adding hte funtionality for different dates can wait
08:39 sjn timezone settings is probably something that should be localized based on user settings, imo
08:40 sjn asking for a custom TZ per-request is a feature we can implement when someone asks for it :)
08:40 dreadnact but if you are defining which fields are returned, its worth thinking about doing this stuff in the future, and how it would work in the api
08:41 sjn .../_c/?newer_than=2010-10-01T20:00Z :)
08:41 sjn we can use Zulu time on EVERYTHING!! MUAHAHAHAHAHH!
08:41 dreadnact so for example I knew of an api where you could specify a field as not included by setting the format to '-'
08:42 dreadnact where 'r' was raw, and 't' was translated
08:42 sjn nah, let's not complicate things too much now ;-)
08:42 sjn plenty of time for that later :)
08:42 sjn KISS FTW
08:42 dreadnact ok, but are you considering how to exclude fields
08:43 dreadnact btw:  .../_c/?newer_than=2010-10-01T20:00Z does not indicate that the timezone of what is returned should be in zulu
08:43 sjn atm, we have the URL parameter hash where we can figure out almost anything
08:43 dreadnact just that the date I have provided is in zulu
08:43 dreadnact completly  different thingds
08:44 * sjn would think it's safe to assume that when someone asks for a date in a certain timezone, they'd like to get the reply in the same one
08:44 dreadnact .../_c/?newer_than=2010-10-01T20:00Z&timezone=gmt
08:44 dreadnact should work
08:44 dreadnact no absolutly not
08:45 sjn why not? (I really shouldn't ask actually, since this is an issue that we can solve later)
08:45 dreadnact assume that the client is using a timezone for calculating stuff, and users in a specific timezone want it in their tz
08:46 sjn client=user
08:46 dreadnact no
08:46 dreadnact client is browser
08:46 dreadnact or flash app
08:46 dreadnact or third party service ona bunch of .net servers
08:46 sjn yes, but you're missing my point
08:47 dreadnact please, whatever you do, dont assume timezone based on the request
08:47 sjn when it comes to timezones, both the client and the user wants a consistent reply according to it's needs
08:47 dreadnact either always use utc
08:47 dreadnact or return the local timezone of the client
08:48 dreadnact dont assume a client asking using a sepcific timezone for there after wants all data in that tz
08:48 sjn if the client/user requests data with one TZ, and expects a reply with another TZ, then they're basically expecting us to do timezone conversion for them
08:48 dreadnact it will mean you will send dates in different tz to the same client
08:49 dreadnact if you always expect utc, and you always return utc, then you offload timezone conversion to the client
08:49 sjn timezone can be stored server-side as the server timezone
08:49 sjn or utc
08:50 dreadnact until such a time that you can implement returing in tz local to the client
08:50 sjn if people expect their local tz, then we can do a conversion, perhaps based on user settings
08:50 sjn if they don't have any, then we supply the tz we have available
08:50 dreadnact yes, but dont do a conversion based on the fact that they used a specific timezone in one of hteir requests
08:51 dreadnact always return the same tz, regardless if they asked for all post in xulu
08:51 dreadnact shit cant type
08:51 sjn if they submit a request for data after a specific time, then they should supply their timezone too, yes
08:52 sjn anyhoo, this can wait :)
08:52 dreadnact .../_c/?newer_than=2010-10-01T20:00Z done by a client in france, should always return the dates in either utc, or cet
08:52 dreadnact never zulu
08:53 sjn (well, zulu=utc, isn't it?)
08:53 dreadnact in fact it would be cet, it would be adjusted, but anyway
08:53 dreadnact dont htey have daylight saving hours
08:54 dreadnact anyway, I recommend for now always return utc
08:54 dreadnact only accept utc
08:54 sjn http://en.wikipedia.org/wiki​/Coordinated_Universal_Time says Z=UTC :)
08:54 dreadnact and then figure out what support you want later
08:54 sjn yeah, let's just work with UTC
08:55 sjn we can jump through the timezone hoops when it becomes necessary
08:55 sjn s/says/claims/ :)
08:55 dreadnact but how to define a filed as included/ommited
08:55 dreadnact which was the original question
08:56 dreadnact not filed, field
08:56 dreadnact damn fingers
08:56 sjn what was the use case for that again?
08:56 dreadnact 300 child comments, when you dont need them
08:56 * sjn sees three use cases: 1) lust thread
08:56 sjn gah
08:57 * sjn sees three use cases: 1) list threads, 2) show one full (or partial) thread, and 3) show one comment
08:58 dreadnact My concern is that you developing an api, not an interface
08:58 sjn for the list, we only have to show the fields that are useful in that context
08:58 dreadnact an api should be as <some word cannot remember> as possible
08:58 sjn no
08:59 sjn apis have to be useful
08:59 dreadnact in the future you have no idea what interfaces will be developed
08:59 sjn they don't have to be complete and supply all kinds of freedoms
08:59 dreadnact and you certainly dont want to have to change the api later for a specific client
08:59 sjn we don't
08:59 dreadnact because then you have to support the old clients
09:00 sjn we need two base actions, plus options to "reduce"/filter those
09:00 sjn that's all we need
09:00 sjn 1) list
09:00 sjn 2) show thread
09:01 sjn list threads*
09:01 dreadnact my point, you should have a generic way of filtering property of any objects
09:01 dreadnact any property, of any object
09:01 sjn any modifications to that (eg. /_c/?regex:id="^.*foo$") can be added as we need them
09:03 sjn .../_c/long_thread_id?only_fields=id,subject
09:03 sjn .../_c/long_thread_id?skip_field=published
09:04 sjn if we really want that stuff, we have room for it :)
09:04 dreadnact when new fields are added, are they shown by default
09:04 dreadnact this will break some clients potentially
09:04 sjn sure
09:05 sjn I have no problem adding fields
09:05 sjn yes, some clients (badly written ones especially) will break
09:06 sjn but I'm not very worried about adding fields will happen too often
09:06 sjn we're making a pretty straightforward tool here
09:06 sjn there aren't _that_ many things to consider, when talking about fields in a comment
09:07 sjn of course, something might show up
09:07 dreadnact ok, well I have to get some work done, but I have some experince where the simplest of api got very complicated very fast
09:08 sjn yes, I have experienced this too :)
09:08 sjn that's why I've built up the api as I have :)
09:09 dreadnact anyway, if child comments are just comments in the comments field, then I am fine with that
09:09 sjn ok, we do the recursive option then
09:09 dreadnact it makes sence, since ou already have full person and location objects as fields
09:10 sjn we can always add a caching layer on the server, if it becomes to much work :)
09:10 dreadnact or create new virtual properties comments_ids
09:11 dreadnact anyway, got to get some work done, talk later
09:11 sjn ok!
09:16 sveinns_ joined #kaizendo
09:17 sjn o/ sveinns_
09:18 sveinns left #kaizendo
10:13 sjn dreadnact: btw, do you know if there's support for internal references in JSON?
10:13 dreadnact not really
10:13 sjn where one node points at another node in the same tree
10:13 sjn hm
10:14 dreadnact you need to specify your own kind of pointer, which the client can understand
10:14 dreadnact is this with locations
10:14 sjn yes
10:16 dreadnact usually it is fine to just include the same element several times
10:16 dreadnact at least locations are small
10:18 dreadnact just have to watch out for circular references
10:18 dreadnact ;)
10:19 sjn mm
10:19 sjn no worries with JSON then
10:20 dreadnact well, if for example locations had a property comments, then generating the json would take forever
10:21 sjn mm
10:21 dreadnact xml has pointers to solve this issue, but you still need xml parsers that understand how to use them
10:22 dreadnact I would recommend for now just accepting that locations will be repeated.
10:23 sjn yep
10:23 dreadnact they are small, and cleverer/more complex solutions can be solved later
10:23 sjn I agree
10:24 dreadnact typically with large objects, you only return the id, and provide a method that fetches the object and caches it
10:24 sjn exactly :)
10:24 dreadnact which is why having get methods is a good idea in js
10:24 sjn that's what I've been advocating earlier today :)
10:25 dreadnact I know
10:26 dreadnact but the overhead of fetching elements is expensive, and since we need all the unique locations at page load, until there is a more efficient method of generating the highlighted html this will just kill performance
10:26 dreadnact not good for demos, or development
10:27 sjn mm
10:27 dreadnact if you want you could provide the filed for the id as well
10:27 dreadnact location_id
10:27 sjn so we put the locations in a seperate array, even if it's repetition
10:27 dreadnact s/filed/field/
10:28 dreadnact just having an array of locations doesnt work, you need to be able to get the comments associated
10:29 dreadnact because you have to count the comments to detemine the highlighting intencity
10:29 sjn locations + depth
10:29 sjn or comment count
10:29 dreadnact yes
10:29 dreadnact (comment_count)
10:29 dreadnact plus age in the future
10:30 dreadnact so so far future
10:30 sjn why?
10:30 dreadnact the age of the last comment chages the hue of the highlighting
10:31 dreadnact its a feature we disussed last tuesday
10:31 sjn isn't it enough to add just a last-modified timestamp?
10:31 dreadnact the location doesnt change, so why update its last modified
10:32 sjn (I'm perhaps a bit confused about what you mean with "so so far future")
10:32 dreadnact to do that you would want a seperate field, comment_lastmodified
10:32 dreadnact oh, that was supposed be not so far future
10:32 dreadnact as in its a feature being introduced soonish
10:33 dreadnact it would really help if I could type *8)
10:33 sjn thread_lastmodified # same date as you use with If-Modified-Since :)
10:34 dreadnact is it practical that every write/add comment, you also require a write to its location
10:34 sjn yep :)
10:34 sjn it's just a post :)
10:34 sjn to the same URL, even
10:34 dreadnact potentially problematic race conditions since locations are shared across comments
10:34 sjn oh, you said "is it"
10:35 dreadnact yes, a ? was implied
10:35 sjn race conditions? how?
10:35 sjn it's not like you're _replacing_ any comments...
10:35 sjn adding a comment should pose no problem at all, really
10:36 sjn you post, and get an id assigned
10:36 dreadnact my point is it may be better to avoid additional writes as there is no agreed long term storage architecture
10:36 sjn what additional writes?
10:37 dreadnact I mean if you update location each time a comment is added/modified that uses that location
10:37 dreadnact location is a different object
10:37 sjn aah
10:37 sjn why would you want to update the location?
10:37 dreadnact or whas the field  thread_lastmodified calculated?
10:37 sjn the location is fixed the second one starts a new thread
10:38 sjn after that, you have to start another thread if you want to change location
10:38 sjn thread_lastmodified is for determining when someone last added a comment to that thread
10:38 dreadnact yes, but I thought you were proposing a field  thread_lastmodified in the location objects
10:39 dreadnact to calculate the hue of the comment
10:39 sjn that's still sensible
10:39 dreadnact but that involves writing the  thread_lastmodified field to location
10:39 sjn hm
10:40 sjn wait
10:40 sjn you need something that tells if there's been a modification lately to the discussions on a page
10:41 dreadnact well, if comments have a date added field
10:41 dreadnact then it can be calculated on that
10:42 dreadnact I guess my point is, if the JSON has a list of comments
10:42 dreadnact each comment has a location property,
10:42 dreadnact and a comments property, which is the comments in reply to that comment
10:43 dreadnact then it is very streight forward
10:43 sjn mm
10:43 dreadnact however it is not ideal in the amount of repeated data being sent
10:43 sjn I'd like to wrap a little context around that
10:44 * dreadnact waits for the wrap
10:44 sjn the context_id (to do a sanity check if the content_text has been changed), a thread_last_modified
10:44 sjn for each thread,
10:44 sjn oh, and atm, I'm talking about the "list threads" feature
10:44 sjn .../_c/
10:45 dreadnact are threads objects
10:45 dreadnact ?
10:45 sjn threads are represented by that first comment that defines the subject
10:46 sjn when listing, you only get what's necessary to create a quick overview of what discussions are available
10:46 dreadnact so comments that have a subject are a thread?
10:46 sjn that's the point
10:46 sjn hm
10:46 dreadnact that have a property comments, which contain the comment in reply to that thread/comment
10:47 dreadnact where is the property thread_last_modified stored
10:47 dreadnact ?
10:47 sjn a thread is the first comment (with a subject, location, etc.) and - if one looks at that specific thread (.../_c/$id), it's attached comments
10:47 dreadnact so .../_c/$id returns a list
10:48 sjn when listing all threads, there's no point in fetching any replies
10:48 dreadnact I thought it would just return the single comment
10:48 sjn well, that's a good question, I've been mulling a bit about that
10:48 dreadnact personally this is why I thought the include/omit fields feature was required
10:49 dreadnact I think you could have some default behaviour
10:49 dreadnact but personally I think it would be useful to get the full list of threads and their replies
10:49 dreadnact perhaps in a discussion summary page
10:50 dreadnact .../_c/$id/comments
10:50 sjn I think atm that the best reply to ../_c/id is enough discussion around that id (before and after) that one can establish what the argument is about
10:50 dreadnact would that be a better url to get the list of replies
10:50 dreadnact ?
10:51 sjn if you want replies-only, many .../_c/$id/replies
10:51 sjn s/many/maybe/
10:52 sjn if you want the complete thread, .../_c/$id/thread
10:52 dreadnact should the field on a comment that contains replies be called replies then?
10:52 sjn that sounds sensible
10:52 dreadnact what is the difference between a /thread and /replies
10:53 sjn if you're asking for a comment id (a reply in the middle of a thread), /replies shows that comment and it's subsequent replies
10:54 dreadnact replies is the list of comments that are in reply to the comment with $id
10:54 sjn and /thread shows both subsequent and preceeding replies, plus originating comment
10:54 sjn s/plus/including/
10:55 * sjn thinks "replies" says something about the timeline of the discussion :)
10:55 dreadnact so thread is like /$id, but where for every comment the field replies is populated
10:55 sjn hm
10:55 dreadnact I am thinking in terms of returned json
10:56 sjn _c/$id should get enough comments that the reader can establish what the current discussion is about (ideally)
10:57 sjn so, if it's a small discussion, just show everything
10:57 sjn if it's a very large discussion, perhaps limit the amount fetched by +/- 10 comments?
10:58 sjn (i.e. if $id is the 50th comment in a thread, then fetch the preceeding and subsequent 10)
10:58 dreadnact thats complicated with threads that split off
10:58 sjn hm
10:59 sjn maybe
10:59 sjn maybe I'm complicating things too much here
11:00 dreadnact I think a more generic solution is that any list can be paginated
11:00 * sjn needs lunch, brb (canteen is closing in 1 minute)
11:00 sjn dreadnact: perhaps
11:19 sjn back
11:20 sjn insta-lunch
11:29 dreadnact left #kaizendo
11:42 dreadnact joined #kaizendo
12:08 * sjn
12:11 sveinns_ is now known as sveinns
12:13 sjn sveinns: http://www.w3schools.com/html5/html5_reference.asp
12:13 sveinns ssm, sjn: The clock at badius appears to go at twice the speed.
12:13 sjn 09:58 < dreadnact> to be honest there is a lot of cleanup to do on the html, for a start we should be using html5 tags, like header,footer,section and nav
12:14 sjn sveinns: time flies when you're having fun
12:20 sjn http://www.nuug-foundation.no/no/​kaizendo-YAPC_EU_2010/index.html
12:43 ssm sveinns: that's a xen problem, I thought it had been solved....
12:43 ssm I'll check it out, it may require a reboot to fix, though
12:43 ssm unless I can set clocksource while running
12:53 sveinns ssm: rebooting is fine by me.
12:56 sveinns I just taught special relativity theory today, maybe badius is travelling at sqrt(3/4) = 0.866025404 times the speed of light?
12:56 sjn rebooting is ok as long as we make sure mojomojo starts again :)
13:00 sveinns I'm sorry, it should be we who are traveling at 0.86c, and badius is standing still.
13:56 dreadnact left #kaizendo
20:37 bleakgadfly joined #kaizendo
23:32 sjn bleakgadfly: hi there
23:35 sjn ssm: apparently, denis knows someone who knows how to fix the time issues on badius

| Channels | #kaizendo index | Today | | Search | Google Search | Plain-Text | summary