Session Start: Mon Jun 24 18:07:51 2002

*** Now talking in #active2

<mike> hi folks

<j> hello!

<mike> hi j

<mike> just got your email re: ender...

<mike> we're just waiting for another person here...scott is here already

<j> good :) ill probly mostly be listening... i guess you gues will be wanting to 'realitychat' anyway :)

<scott-van> i'll get keith too!

<mike> yeah, mostly, i guess. i'll try to transcribe what i can realtime...unless i'm talking ;)

<j> this is going to be a little experimental, i guess... from this end its best to just be prepared to expect delays - mike:  hopefully this doesn't make the meeting *too* miserable for you!

<meta> grav just showed up... he will be here shortly and then we can go i guess

<mike> grav got here, too; he's setting up his wireless...

*** Anton has joined #active2

* Anton yawns..

<Anton> hi

<scott-van> hello

<scott-van> are you exhausted?

<Anton> well.. tired ;)

<j> hello anton

<mike> hi anton

<Anton> ok, hi jason :)

<Anton> hi mike

*** grav has joined #active2

* grav sends greetings

<mike> so, this will be a little weird ,i guess. i'm going to try and transcribe stuff as people say things here...

<Anton> mike: yeah, it keeps me awake at least ;P

<mike> (when i'm not talking, that is ;)

<scott-van> the intention of this meeting is to produce a design document that we can distribute widely for comments

<Anton> mike: do your talk mostly, just summarize some here as good as you can 

<scott-van> i will summarize...

<Anton> since it's very uncommon to meet in person, i think you should take your time to do that firstly

<scott-van> three areas - a backend, a middle and a front-end

<scott-van> user interface incl html, pdf, xml, etc. are front end

<scott-van> lexicon: story is what you typically see on IMC now (also commonly called an article)

<scott-van> lexicon: content is a comment or a picture

<scott-van> content can be stored however you want and it is referenced via a filekey

* Anton just installed FreeNet on his newly installed copy of Mac OS X btw.. still haven't got much more clever though ;)

<scott-van> three fields: 1 is imc that originated the content, 2 is the mimetype, 3 is a hash of some kind 

<scott-van> article consists totally of metadata

<scott-van> metadata links together filekeys and content into stories

<scott-van> backend will be compatible with p2p tech (gnutella, freenet, circle, etc.)

<scott-van> backend can/would be on different machines than the front end

<scott-van> middle layer should be caching stuff

<Anton> scott-van: make sure you straighten out the stuff regarding what a Comment is commenting on - if it's a new comment for each Translation and/or if a Translation is unique for each Comment (hope you get what i mean). If this is already figured out, just put it to the protocol for all to see

<scott-van> middle layer would be tracking user sessions, etc.

<Anton> ...since translating a Content is not translating an Aricle

* Anton agress on everything so far though

<scott-van> hold on... there's a bit of a f2f conversation going on re: what's middle and what's front

<Anton> ok :)

<Anton> middle is what delivers the front, right? backend is what generates the middle

<scott-van> exactly

<scott-van> anton: you can comment on anything that has a filekey...

<Anton> ok, great. but the same goes for translations, right?

<scott-van> filekey x is a translation of filekey y

<Anton> ah. ok.

<Anton> the link is stored in the Article (metadata) ?

<Anton> (the <filekey x>  <--->  <filekey y> i mean)

<mike> we're sort of hashing out what an ``article'' might be

<mike> two main contenders:

<mike> 1. just a unique-id somewhere which rdf-assertions reference

<mike> 2. a file-like object with a filekey

<mike> that is, something which looks like a file and has a filekey id, but can change

<mike> i don't like that, because it's hard to change things on P2P networks

<Anton> which one is hard, the latter one?

<mike> yes

<Anton> i guess you guys are the ones to chat about this issue - it goes beyond my knowledge or suggestions..

<mike> ...talking about ugly urls

<mike> i brought up the alias idea from earlier...

<mike> where individual IMCs can define aliasses to real article links

<Anton> using mod_rewrite?

<mike> that is ``2002/06/02/mike_o_rama'' really means ``article/filkey/version'' or whatever

<mike> cannonical url would still be the /article/filekey/version or however we define syntax to reference versions

<mike> ISO dates has been suggested here

<mike> shoulds good to me

<mike> (and scott and grav)

<Anton> sure

<Anton> YYYYMMDD ?

<mike> Anton: yes, plus time

<Anton> great

<Anton> the p2p storage seems to be a critical part to go trough..

<scott-van> yeah... that's something that I think is really crucial

<Anton> are you discussing if the metadata (Article) or Content should be stored there?

<mike> Content

<Anton> should Content be accessible via URLs, without going through an Article?

<Anton> (maybe typical 3 AM questions..)

<j> i think it totally should - but im  confused too - where metadata lives on backend?
<mike> that's kind of an open question

<mike> see above.. ;)

<mike> basically i'm leaning toward rdf assertions which point to a unique article-id

<Anton> would this mean that the "link" is p2p:ed but not the Content itself? or is it just another way of "doing it"?

<Anton> (by link i mean metadata links to different Content items)

* Anton gets a sandwich...

<scott-van> two step process: a request fetches the metadata and then fetches the content

<scott-van> different imc's store and index their own content

<scott-van> not clear how metadata is stored (yet)

<j> but it should be global to the entire network?

<scott-van> absolutely

<j> so it shouldnt matter, as long as servers can recognize the name... ? <reaching>

<mike> so, what were thinking:

<mike> rdf-assertions are stored in immutable files (i.e. one assertion per file) and hence can have a filekey each

<mike> IMCs make intexes (almost certainly in SQL database) which tell which rdf-filekeys belong to which article-keys

<Anton> when you say "article-key", is this the metadata file for the content(s)?

<Anton> ..or did you mean "content-key"?

<mike> article key is a unique key for a particular article

<mike> (articles consist of lots of Content, remember)

<Anton> yup

<Anton> so, the "index" is the newbie here, right?

<mike> huge points out: only about 50 or so articles live at a time * a few hunder imcs = manageable index

<mike> Anton: yes

<Anton> ok, thought it was an acronym for Article first.. :*)

<Anton> hm.. would 50 live articles be a limit to live with? what are your thoughts..?

<mike> no, not limit

<mike> just a sec

<mike> okay

<mike> just that the index wouldn't be too big at any one time

<Anton> ah, ok

<mike> ...if older articles are requested, then it might take a bit of time to rebuild the stuff for that article...

<mike> (that is, find all the Content associated with it).

<Anton> yeah, i follow

<Anton> ;)

<mike> back

<mike> we've also talked about a middle-end, too

<mike> it would be where the datastructure representing the article lives (the ``stream of python objects'' talked about earlier)

<mike> this basically boils down to some well-defined structure which the backend parsers produce and the front-end parsers know how to translate into {html,pdf,text,rss feeds, etc}

<mike> also, it makes sense for the middle-end to tract things like user-sessions (logins).

<Anton> yeah, nice

<mike> anton's gUI stuff:

<mike> http://andreasson.org/Active2/news1.html

<mike> what else, anton?

<mike> there's links, right?

<mike> grav will take a look...

<Anton> oh.. i've installed apache now ;)

<Anton> new link:

<Anton> ../^antona/Active2/Utopia/ i think

<Anton> ~antona/...

<scott-van> what's the full URL?

<Anton> (it's in the wiki btw)

<Anton> hang on..

<mike> oh, ok

<Anton> http://andreasson.org/~antona/Active2/Utopia/index.html

<Anton> just some GUI things that came to mind during this session:

<Anton> the Content list section on the right bar (when viewing an article) is very similar to sf-active's Article list, which is kinda bad..

<Anton> what if we could list the contents under/in/within the active article instead?

<Anton> and keep the right hand bar for "other articles in this newswire/feature" (as sf-active)?
<Anton> </end>

<Anton> the middle bar is where i consider the content to be viewed, hence the Comments and Translations are found there now..

<Anton> the right is for related stuff to what's viewed..

<Anton> and the left is what links to the middle, kinda like an flow of info, from left to right

<Anton> (could be made more clear, that's the idea anyway)

<Anton> http://andreasson.org/~antona/Active2/Utopia/news1.html   <--- article (link was hard to find i noticed)

<mike> Anton: which was the link to the neat newswire admin page?

<Anton> oh, it's below the news list ..

<Anton> http://andreasson.org/~antona/Active2/Utopia/admin/admin_news1.html

<mike>  http://andreasson.org/~antona/Active2/Utopia/index.html

<mike> oops

<Anton> i made the bg yellow as an indicator of "admin mode"

<Anton> (could be set by the imc admins if necessary ;)

<mike> hmmm. this isn't like i remember

<Anton> Doug is a fan of changing colors - i'm not ;)

<Anton> ok..?

<mike> was there one to administer what goes into the front-page?

<mike> doug was showing it to me a couple weeks ago

<Anton> oh.. hang on

<Anton> that was the article admin page, for the Author

<Anton> http://andreasson.org/~antona/Active2/Utopia/admin/

<mike> i'm looking for the one which can combine newswires...

<Anton> (just browse it)

<mike> okay, this is it

<mike> http://andreasson.org/~antona/Active2/Utopia/admin/admin_newswire.html

<Anton> yup :)

<mike> i think this is really cool :)

<Anton> i think the links work too there, right?
<Anton> thanx :)

<Anton> as you can see we'll have other delicate problems to deal with later on, like approving new Newswire members ;P

<mike> hugh was asking about getting feeds from others sites (i.e. other IMCs or non-IMCs)

<Anton> (and kicking and assigning access..)

<Anton> ok.. could be another newswire item

<mike> we think rss is a good idea for this; one of the things you could add to the middle might be an RSS feed from elsewhere

<mike> Anton: yes

<mike> so, this could use info from even non-IMCs

<Anton> (the select menus at the top shows some of these already)

<Anton> mike: true

<Anton> if wanted, and allowed in the code :)

<mike> yes

<Anton> you're with me on the difference between the Author admin page and the Newswire admin pages, right? I think there's a need for this distinction

<Anton> since different people are probably going to use them

<mike> what does the author admin page do?

<mike> thats admin_news1.html?

<Anton> NGOs would probably create a Newswire of its own while Freelancers would mainly be producing content, i guess

<mike> that allows the author to associate Content with their Article, right?

<Anton> it enables the Author to edit his/her Article

<mike> yes, i'm clear on that

<mike> ...while the newswire either includes and Aritcle or it doesn't.

<Anton> yes, and remove and maybe applying Proposals (an old idea from Dru)

<Anton> mike: yes

<mike> what are proposals

<Anton> well.. its just a comment basically

<mike> okay.

<mike> uhm, scott suggested i sumarize

<Anton> but the Author could say "aha, that was a better way of putting it, i'd like this text instead of mine!"

<mike> objections? more questins? 

<mike> Anton: okay, yes, that's good

<Anton> no, go ahead over there :)

<mike> okay:

<mike> backend:

<mike> 1. contains file-like things, which are immutable

<mike> 2. each thing has a filekey

<mike> 3. RDF assertsions come one-at-a-time, with a filekey for each

<mike> 4. articles have unique IDs (not necessarily filekeys, but could be)

<mike> 5. IMCs maintain indexes of which RDF filekeys are for each article

<mike> middle:

<mike> 1. defines datastructure for representing Articles

<mike> 2. has input parsers which translate information from the backend into this datastructure

<mike> 3. tracks user logins/sessions

<mike> front: has output parsers which translate middle-end datastructure into presentation (pdf, html, etc.)

<mike> (that is, it's the user-interface)

<mike> so, that's it

<Anton> ok, great work

<Anton> I might add that I currently don't update the GUI drafts too much - kinda waiting for the tech discussion to catch up I guess

<mike> i'll produce a design document from this at some point

<mike> (probably not this week; pretty busy)

<Anton> if i get my hands on a Python coder here (which i might do ;) can i tell him to start developing something or is it too early?

<mike> any other questions/comments/concerns

<mike> Anton: tell him to check out the proof-of-concept stuff and this discussion (although this supercedes anything in my code...)

<mike> also useful to look at cheetah stuff

<mike> i would say it's not too earlier to have some better prototype/proof-of-concept type stuff hacked out

<Anton> ok, i think he is installing your stuff at the moment, will tell him about Cheetah too
<mike> then, we'll discover problem in the design ;)

<Anton> heh, true

<mike> ...but that's good :) that's not a bad way to code IMO

<mike> (that is, make some code and see exactly where the hard problems are...)

<mike> tell him to email me if there's questions/comments about the stuff i made a couple weeks ago or whenever... ;)

<Anton> sure

* Anton yawns..

<Anton> nah, it's getting late now..

<Anton> the sun's rising here ;P

<Anton> hm.. i think i'm off too now

<Anton> will post the logs tomorrow if no one else does it before me

<grav> but it was nice hanging out anyway :)

<grav> hopefully mike will keep in touch

* grav waves

<grav> bye for now

*** grav has quit IRC (Client Exit: ircII EPIC4-1.0.1 -- Are we there yet?)

<Anton> yeah, bye all!

*** Anton has quit IRC (Client Exit: zzzzzzzz...)

Session Close: Mon Jun 24 20:24:09 2002