-:- Starting logfile IrcLog
IRC log started Wed Aug 21 13:09:15 2002
-:- Value of LOG set to ON
<Anton> (i don't mean that is has stuff noone else has but my first 
impression was very good)
<mike> hi anton,humble
<humble> hi mike
<Anton> hi mike
<humble> cvs is up and running I understand??
<mike> yes
<mike> on hiro
* Anton/#active2 thinks it's nice with chatzilla in mozilla :)
<mike> i haven't imported all the code i have in my own cvs yet, tho
ugh
<mike> Anton: yeah, you get to click on all sorts of things ;)
<mike> i just installed gnats, too, but haven't configured it yet
<Anton> yup :) and i don't need to launch another app
<mike> is gnats cool for a bug-tracking system?
<Anton> no idea. haven't heard of it nor do i know its competitors m
uch
<mike> it's what i use at work
<mike> email-based, plain-text-files, web interfaces, pretty configu
rable
<mike> ...but i'm not too familiar with others, either...
<Anton> although, i'd love a place (generally speaking) where ppl ca
n add comments about features or possible bugs so that we can get notified easily
<mike> yes, me too, especially useful later on...
<mike> (i.e. when there's more people/more code involved)
<humble> should we add links to gnats and the cvs stuff to the wiki?

<mike> sure
<mike> we should also solicit ideas for categories of PRs and so on
0m
<mike> i think this can change mid-stream, though, so a preiliminary
 set is fine...
<Anton> hm, have you guys registered at the new twiki yet? i don't k
now if i have but ppl seems to use the old one still(?)
<humble> yeah... I'm all over the new wiki (metamatrix)
<mike> i would think: backend, frontend/gui...
<mike> metamatrix?
<mike> is that what doc.indy runs?
<mike> ...i thought it was twiki?
<Anton> it's your nick?
<Anton> it's your nick?
<humble> no... my handle on it
<mike> oh. yeah, i'm registerd too, i think (mike? mikewarren?)
<humble> yeah... i forgot my password for humble and it was too much
 of a pain to track down :(
<mike> keith should be able to reset it; he did for me :)
<mike> ...but i don't know how myself :(
<humble> for docs?
<humble> ender is also running twiki
<mike> should we work down the agenda?
<humble> yeah
<Anton> i succeeded in installing a twiki on goteborgsfria.nu/twiki 
which i'm very proud of :)
<humble> congrats!
<mike> okay, well, we've already done some of 1. (did you see the po
st humble?) so do we need a policy for new accounts on hiro? 
<Anton> list participation?
<humble> we should definately have a policy... list participation is
 the obvious one
<Anton> required i mean..
<humble> yup
<Anton> roll call on the list?
<mike> yeah. but beyond that? an account implies check-in ability, r
ight?
<Anton> oh
<mike> one second, no blocks on the list?
<mike> or more seconds?
<mike> we can always have anonymous cvs access for check-OUTs...
<Anton> seconds like "ok for me" ?
<mike> well, someone would propose ``mike should have a hiro account
''
<mike> ...and then two people would need to say, ``yes, that's good'
'
<humble> a second from someone who partcipates actively would be bet
ter
<mike> ...and nobody blocking would imply an account for mike
<Anton> ok i see, just a new word for me :)
<mike> humble: okay, that sounds good: second from someone with cvs 
checkin access?
<humble> yeah... build the web of trust (been reading my gpg docs ;-
)
<mike> ;)
<Anton> sounds good
<mike> i have no problems with that policy
<mike> i'll volunteer to write it up and post to list.
<humble> make can you be point person for setting up news accounts?
0m
<Anton> an "active list member" can be fuzzy so cvs member is better

<mike> (not that that's a huge job ;)
<mike> humble: sure
<mike> okay, so that about covers 1 unless there's more bug-tracking
 stuff to cover...?
<humble> cool... until I do more reading on the linux security model
 I'd rather not be the point person
<humble> present accounts on hiro are keith, me, mike, tannis (my gi
rlfriend) and ingo
<humble> I'll look at setting up a backup system (rsysnc to another 
machine, etc.)
<humble> how does gnats work.. is there a web interface?
<mike> okay, i didn't know ingo was on there, too.
<mike> scott has account too right?
<humble> that's me :-)
<mike> (uh, scratch taht...)
<mike> so, mike, scott and keith are in active2 group
<Anton> is cvs similar to the versioning in a twiki?
<mike> (i.e. have cvs-checking access and ability to screw with the 
repository)
<mike> Anton: yes
<humble> can we add ingo?
<mike> yeah, i will. login is ``ingo''?
<humble> yeah
<mike> okay
-:- IanB [ianb@dialup-64-34-3-52.telocity.co
m] has joined #active2
<humble> hi ian
<mike> hi iean
<mike> ian
<IanB> hullo
<Anton> i have a programmer friend who said he'll introduce me "hand
s-on" to cvs soon..
<Anton> hi ian
<mike> Anton: if you know emacs, there's an emacs interface...quite 
nice, but i'm an emacs slut ;)
<humble> Anton: can you webcam that? ;-)
<mike> IanB: any thoughts on agenda item 1? we've basically covered 
it
<Anton> heh.. not from my place, no
<IanB> Anything that works... SF doesn't actually have all that many
 useful services, IMHO
<IanB> The CVS is useful, and the web page/domain is useful.
<IanB> Otherwise, at the beginning, all the nitty-gritty (bugs, etc)
 can just happen on the mailing list
<IanB> Maybe with a -devel mailing list.
-:- You have new email.
<mike> yeah. gnats can also be configured to post, say, all changes 
to all bugs to such a list...
<humble> maybe an active2-bugs list?
<mike> IanB it looks like we've basically decided to not use sourcef
orge
<mike> (which is fine with me...)
<Anton> -devel sounds more pro IMO :)
<mike> humble yeah
<humble> i liked savannah better anyway
<mike> okay, -devel?
<mike> (i agree it sounds more ``pro'' ;)
<IanB> Maybe that's silly, though...
<humble> although the present list is Active2-dev ?
<IanB> there aren't anything *but* developers at this point.
<mike> oh yeah.
<Anton> it's not a biggie..
<Anton> whatever does the job
<Anton> -feedback would be a more friendly word in that perspective(
?)
<humble> why don't we keep it to one list for now until there's more
 of a clear need for more lists??
<Anton> -bugs.. well, works too i guess..
<mike> yeah, works
<mike> so, should we move on?
<Anton> humble: good point
<IanB> I agree with humble -- everyone who'll be on one list will be
 on the other.
<Anton> so, #2 coming up?
<mike> could we do 4 next? probably shorter..
<humble> once we have a prototype working I can see wanting to give 
another address for beta-testers to send comments to, but until then...
<mike> humble: yes
<humble> let's do #4!
<mike> 4. scheduled coding session(s)? (as per suggestions.) 
<Anton> sessions..
<mike> that is, scheduled coding sessions (co-ordinate via IRC)
<mike> ?
<mike> good idea?
<humble> I'm moving at the end of this month so things will be a lit
tle bumpy for hiro around that time
<Anton> idea cool. time etc is cool for me this time of the day. you
?
<mike> i'm going cycle-touring at end of month
<mike> perhaps in sept?
<Anton> i don't know if i'm coming in to the picture already at the 
end of the month..
<mike> weekends would probably be best for me (or evening)
<Anton> me too
<humble> we're talking about a concentrated codefest right?  let's p
ick a weekend in sept?
<mike> so, weekends i guess (timezone wise)
<mike> humble: yes, concentrated
<mike> second weekend
<mike> ?
<Anton> is that the 14th?
<humble> yeah 13th - 14th
<humble> (not good for me)
<mike> so how about 14th?
<mike> oh
<mike> third weekend?
<Anton> all weekends in september seems to work for me (if school do
esn't change that on monday..)
<humble> the weekend after would be better for me (but I'm not much 
of a coder so don't let me hold it up)
<mike> IanB, how is 13/14th?
<Anton> Friday the 13th?
<IanB> I think that would work... I'm out of town before that, but I
 think I should be back by then.
<mike> sunday...
<Anton> *phu*
<humble> suday the 15th?
<mike> yeah, or sat. how about we schedule sunday, and i'll be hangi
ng out here if anyone else wants to come and play...
<mike> (the 15th that is)
<IanB> sounds good
<mike> okay.
<Anton> ok for me, depending on time zone
<mike> 5. is there a better meeting time which would result in more 
people 
<mike>    attending meetings? 
<humble> how about a 24 marathon?
<mike> (this time is ``okay'' for me...)
<mike> humble you mean coding-wise
<humble> yeah... sorry 24hour
<mike> i don't know if i'll last that long, but i can try ;)
<Anton> ingo and me have the worst troubles i guess since we're GMT+
1 here
<Anton> 21.30 now..
<mike> yeah, i'm gmt-7
<Anton> (and sweden have summer time now: gmt+2)
<humble> i'm gmt-8 i guess
<mike> well, i'll try to be around #active2 as much as possible on t
hat weekend...
<Anton> but as i said, this time is ok for me - i'm just to be up ra
ther late. the 3am meeting last month(?) was a killer for me though..
<Anton> doh - used
<humble> why don't we just say it's all that weekend and will be hap
pening via #active2??
<mike> okay
<mike> #5-wise, i guess this is about as good as any other time, it 
sounds like...?
<Anton> sure
<humble> so, we can announce the cvs policy and the time and place f
or the codefest and see who else pops up
<mike> coding-wise, we could always coordinate locally (i.e. humble 
and i are nearby timezone-wise, for e.g.)
<mike> humble: yeah
<Anton> yeah, this is about the earliest you guys can make it, right
?
<mike> Anton: i can make it earlier 
<mike> four hours earlier would put it at 9am my time, which is usua
lly much before i go to work
<mike> 10am would be fine, too (also before work, usually)
<Anton> ok, but on weekends only, right? don't you have lunch at thi
s time otherwise..?
<Anton> ok..
<mike> so we could move the meetings three hours earlier, at that wo
uld be good
<mike> Anton i can take lunch whenever
<mike> is 3 hours earlier better for people? humble? ian?
<humble> yep... even better for me
<mike> better for me too
<mike> anton?
<IanB> That's fine for me.
<Anton> just good to know. i'll probably be checking in #active2 at 
both times
<Anton> good then :)
<mike> okay, let's move the official meetings to 3 hours earlier 
<mike> that's 1700 GMT?
<Anton> guess so yeah
<mike> okay, so we can move to #2/#3
<mike> 2. more discussion of internal representation of documents. 
0m
<Anton> no, wait.. this meeting was 19.00 GMT i think
<mike> 
<mike> 3. templates: output filter architecture greatly affects how 
templates 
<mike>    will be written/used. 
<mike> Anton I'll double-check and then annouce
<Anton> great
<mike> it's 1300 my time, so we'll move to 1000 my time...
<mike> does that close 5?
<Anton> :) sure
<mike> okay, so 2/3
<mike> IanB you were talking about xml on the lists...
<IanB> Well, I don't know if XML means much more not, with respect t
o the documents.
<mike> i think i still prefer a python-object-tree type approach, bu
t xml could work (and could be done via SAX parsing for speed...)
<IanB> I may have just been confused at the time.
<IanB> I think we should stick to string representations of most con
tent, not complex objects.
<IanB> For things like images and HTML, strings are canonical and ef
ficient.
<mike> well, the objects aren't that complex; they're just encapsula
ting pre-parsed information
<mike> (semantic information that is)
<mike> this means less work for the front-end
<mike> (which is the idea)
<IanB> But it complicates caching and transfering the documents.
<mike> (well, at least that's why I proposed it ;)
<mike> not transferring; that's up to the backends (etc.) which keep
 the content as-is (i.e. as submitted)
<mike> caching is complicated slightly if we want to cache the post-
input-filter documents
<mike> (but really, it would just be a python hash table...)
<mike> remember, i'm talking in-memory representation here...
<IanB> I guess I'm just not clear on why its necessary.
<mike> just a division of labour from middle- to front- end, basical
ly
<IanB> I would assume we'd do some transformations to the HTML befor
e displaying it
<mike> ...trying to keep complications away from the front
<mike> IanB my idea is to do the tranformations on the internal (mem
ory) representation only. that way the front end understands exactly one input format:
 the memory representation
<mike> here's the steps i envision:
<mike> 1. user submits content A in HTML
<mike> 2. stored in backend as HTML
<mike> 3. different user requests the content via the web (i.e. thro
ugh the frontend)
<mike> 4. frontend requests document via middle-end
<mike> 5. middle grabs the HTML from the backend 
<mike> 6. middle passes HTML through input filters, resulting in the
 memory-representation
<mike> (that is, a python Document object)
<mike> 7. front end gets the document object and gives it to filters
/templates to render as the web-user wants
<mike> step 1 might be other format, though, like plain text, etc.
m
<mike> the rest would be the same, though, no matter the backend for
mat
<IanB> Performance-wise, I think caching the transformed HTML will b
e very important.
<IanB> Ditto transformed images (i.e., thumbnails).
<mike> IanB yes, the middle would cache the python-object representa
tion
<mike> (and it's all in one process, so all web accesses can benefit
)
<mike> the middle would handle thumbnailing too.
<IanB> I guess I'm still unconvinced of the utility.  The string rep
resentation is very easy to work with.
<mike> what ``string representation''?
<mike> HTML?
<mike> PDF?
<mike> plain text?
<IanB> All of them.
<IanB> Even images are just strings.
<mike> well, then the front-end has to parse them
<mike> ...*and* transform them
<mike> i think the front-end will be the most likely to be modified 
by people, so it should be easiest (IMO) to work with
<IanB> I think those transformations are going to be very ad hoc -- 
there's not a lot of similarity between image transformations and HTML transformations
, for instance.
<mike> i just don't see why the front end should be parsing HTML/PDF
/etc. (who would cache the results? it woldn't really be possible to do so)
<IanB> I almost feel like the backend could do it.
<mike> IanB well, no, there's not, but that doesn't affect the docum
ent representation (the document iwll contain images, for e.g.)
<mike> IanB if the backend does it, how does it give it to the front
 end?
<mike> (that is, in what format)
<IanB> Well, in the case of HTML it just does basic formatting...
<IanB> stripping malicious tags, maybe inserting some CSS classes.
m
<mike> what if they want to change the design?
<IanB> Then it gives that format.
<mike> how does it know?
<IanB> I think CSS would be sufficient.  There'd still be templating
 available.
<mike> (are you saying designers would need to modify the backend co
de?)
<mike> CSS is not sufficient
<IanB> Where wouldn't it be sufficient?
<mike> it can barely do more than change colours
-:- You have new email.
<mike> you can't make sweeping changes to the design (for example, c
hanging <h1> into a <div> tag)
<IanB> I suppose... you could index things, and do other sorts of tr
ansformations.
<mike> ...or making <h1>'s be wrapped with a table instaed
<mike> the backend should not be doing design-type stuff; it's a sto
rage medium (IMO)
<IanB> I suppose... but all those transformations can be done on the
 string as well.
-:- kers [~kers@hd5e25c6a.gavlegardarna.gavl
e.to] has joined #active2
<mike> or what if someone wants to display the titles with the dates
 right under them while other sites don't want the dates, or want it in the byline, or...
<IanB> It's slightly more expensive if it gets converted to and from
 a string/tree several times,
<mike> IanB it goes string->tree->string
<mike> just once
<Anton> hi kers! (swede)
<mike> you're talking about forcing the frontend to parse (string->t
ree) and transform all by itself. How can the tree object be cached in such a situatio
n?
<mike> (at least, that's waht it sounds like)
<kers> hi anton, and everybody else ! 
<IanB> Only string objects should be cached, IMHO.
<mike> hi kers
<IanB> Hi Kers.
<mike> ...but then you don't save the parsing time
<mike> (ever)
<IanB> You should cache the resulting transformation.
<IanB> I.e., cache the (almost) final output.
<IanB> Then use that to fill in the template.
<IanB> The template should handle displaying metadata and larger for
matting.
<mike> but the final output may very well be different on a per-user
 basis (for example)
<IanB> I think performance is too important to let the internal stru
cture of the HTML be user-dependent.
<IanB> I can imagine it would be useful to allow the user to customi
ze aspects, like having syndication in sidebars and the sort.
<IanB> That can be cached on a per-user basis, as well.
<mike> it isn't that hard to emit HTML from a parse tree
<mike> (or what is essentially a parse tree)
<IanB> But if the user can customize the HTML, then it's difficult t
o cache, because you have to cache on the (user, article) pair.
<mike> ...that is, a stripped-down representation of the semantics o
f the document
<mike> no, you just cache the parse-tree object and forget about use
rs
<IanB> Then you are converting the parse-tree to a string for every 
article view.
<IanB> That's expensive.
<IanB> I just don't see what it buys you -- user customization of we
bsites just doesn't happen.  Users don't care enough to make thoughtful/useful customi
zations.
<humble> IanB: wouldn't the multi-lingual nature require this? 
<mike> what if they have preferences, like times are 24hour, etc.?
m
<Anton> it's not _those_ users, it's installer users too - imcs.. an
d they're not all techies
<mike> humble good point
<IanB> Dealing with multiple languages is orthogonal to this, I beli
eve.
<mike> Anton yes, ``users'' are also ``imc techies/designers''; i wa
nt to keep their code as simple as possible
<IanB> The parse tree won't help you -- the entire document has to b
e translated by a human, and stored in the backend.
<IanB> IMC techies will have access to the templates for their site.

<mike> IanB i know, but the code to change the look/feel/user-option
s should be as simple as possible
<mike> they shouldn't have to worrk about parsing PDFs into HTML
<mike> (just internal-format into their-own-pretty HTML)
<humble> IanB: not if you're going to be wrapping swedish controls a
round the contents, or what about delivering to hand-helds??
<Anton> is it a problem to cache a lot of (different) data? that see
ms to be an issue in the conversation, no?
<mike> i mean, what happens when we want to support a new submission
 format? do all the frontends have to change?
<IanB> The swedish controls will be in the template -- the document 
will never contain controls.
<mike> if the middle parses formats into a known target, then the an
swer is no.
<humble> ( i think I used 'control' incorectly ;-)
<mike> and how about producing formats like RSS? these types of thin
gs have many non-trivial transformations.
<mike> (that is, non-trivial from HTML)
<mike> ...or producing PDFs, for that matter: if the backend is givi
ng out HTML, then the front end would have to parse *that* HTML and produce a PDF from
 it...
<mike> (sorry, menat middle-end)
<IanB> Format conversion is another aspect...
<IanB> but I don't think a tree-representation helps there.
<mike> if the middle-end is giving out a tree in a known format, the
n the front can easily make (PDF,HTML,RSS,LaTeX,etc.)
<mike> ...and the front doesn't have to change at all if a new input
 format is supported
<mike> (and likewise, the back/middle doesn't change if a new output
 format is desired)
<IanB> The tree format from HTML is vastly different from the tree f
ormat for RTF, for instance.
<IanB> The frontend would have to be changed if RTF uploading were a
dded.
<mike> the ``tree'' format would be our own internal object, not a r
eall html parse tree
<mike> IanB no, the front would not change if rtf uploaded were adde
d; the middle would still parse to the same internal tree
<IanB> Okay... for clarity, what would the internal format for an HT
ML page look like?
<mike> (that is it would translate rtn->internal tree)
<mike> s/rtn/rtf
<mike> the stuff in actvie2.document.* in my current example code
<mike> sorry active2.document.*
<mike> the internal tree would look the same no matter what it was p
roduced from (that is, the HTML tree would look the same as an RTF or PDF or plain tex
t tree)
<IanB> Now I'm more confused then ever... how would you manage makin
g a PDF and HTML file look the same?
<Anton> filter once.
-:- You have new email.
<mike> not the files, just the in-memory results of parsing them (i.
e. ``input filters'')
<mike> so an input filter is responsible for converting a format int
o the internal memory-representation (``tree'')
<mike> i have an example of a plain-text one in my code now
<IanB> The parse tree for HTML is obvious enough, but for PDF I don'
t know what a parse tree would even look like.
<mike> forget i mentioned ``parse tree'' ;) 
<IanB> Where's the code located?
<mike> i just mean the internal tree-like document representation
<mike> there's instructions for anonymous CVSing it from my computer

<mike> (on the mailing list)
<IanB> We're talking about the internal content, right?  Not the met
adata?
<mike> (actually, sorry, viewcvs will let you download a tarbal)
<mike> yes
<mike> (just a sec, i'll get the url)
<IanB> http://meejah.homeip.net/cgi-bin/viewcvs.cgi/projects/indymed
ia/active-2/python/indymedia/
<IanB> No...
<IanB> http://meejah.homeip.net/cgi-bin/viewcvs.cgi/projects/indymed
ia/active-2/src/active2/
<mike> yeah, sorry
<IanB> active2.document.filter.input ?
<mike> that's the base
<mike> yes
<mike> there's plaintextinput i think
<mike> it basically just looks for titles which look like ``* Capita
lized Title''
<mike> everything else is paragraphs
<humble> i gotta run soon...
<IanB> Okay, I looked at the code some, but maybe we should move on.

<Anton> it's good to discuss unclarities though..
<mike> humble okay
<mike> IanB okay
<mike> Anton i agree
<humble> what else to cover?
<Anton> but maybe move on a bit to output filters?
<mike> well, i think we discussed both :)
<IanB> Yeah, it's all one ball of wax.
<mike> the output filter arch. will affect the template architecure,
 though...
<Anton> oh.. i see :)
<mike> ...but, uhm, perhaps more robust example-code would clarify i
ssues there...
<mike> i have to leave soon, too
<mike> is that about it?
<IanB> I suppose so.
<mike> so, next week except 3 hours earlier?
<Anton> sure :)
<IanB> Okay.
<mike> I was logging; i'll post logs
<mike> ...and a summary
<mike> well, thanks for the meeting
<mike> see you all next week, if not sooner...
<humble> great!
<humble> see y'all
<IanB> Okay, see y'all later.
-:- humble [~scott@s142-179-110-234.bc.hsia.telus.net
] has left #active2 []
-:- SignOff IanB: #active2 (Client Exit: 
Client Exiting)
-:- mike [mike@h24-67-116-97.cg.shawcable.net]