ICB log 4.4.95

<acet> methinks tunachat client might work well with dual-screen type
<acet> interface... one screen looks much like irc client, other
<acet> screen looks much like tin and is used for selecting group
<acet> servers
<acet> only one needs to be active at a time though
<xentrac> hmm...
<xentrac> might want a third screen for selecting groups
<xentrac> instead of typing silly command lines /g whatdoyoumeanyoud
<xentrac> /join #whatthehelldoyouthinkyou'redoing
<acet> hrm, that requires the client getting a complete list of
<acet> currently registered groups.
<xentrac> acet: not necessarily.
<xentrac> you could just ask one server for a list of all groups...
<xentrac> or ask a person for a list of groups...
<xentrac> or ask a group for a list of groups...
<acet> client could pull lists from multiple group servers (all of
<acet> them tagged in tin-like mode)... then groups could be listed
<acet> down the screen (again, like tin article reading)... something
<acet> like Group1:OnServerFOO  16 users  
<acet> (rvl) or whatever
<xentrac> groups could be 'linked' to groups that were closely related
<ick> wait! this is clientserver! no groups
<ick> ugh.. how to specify server on cammndline in irc? it freezes irc.colorado.edu since that is my default
<xentrac> or you could qualify your requests... all groups with fewer
<xentrac> than 10 people
<xentrac> ick: why not?
<acet> ick: then ignore us (they will eventually be merged, no?).. we
<acet> still haven't decided this issue so might as well do so
<xentrac> hit ^C
<xentrac> then type /server irc.santafe.edu
<ick> notworking
<xentrac> or you can say irc irc.uiuc.edu
[=Error=] Server error, attempting to recover, please wait...
[=Error=] Server is back up and running...
<xentrac> seems like having people register groups with groups they're
<xentrac> in, as well as big-daddy group-servers, would significantly
<xentrac> increase scalability, as well as utility.
<ick> yay! irc groks sigwinch
<xentrac> it'd be nice to see what groups people in my group own... or
<xentrac> are member 
<xentrac> members of.
<acet> xent: hrm, how about irc/tin hybrid interface... a few lines
<acet> at the bottom of the screen that scroll in their own little
<acet> window (command line type interface)... the top window lists
<acet> groups and so on that can be 
<acet> selected. Client can keep a buffer of all the groups it knows
<acet> about (from /g commands to various servers)... and user can
<acet> use command-line completion and other features to select
<acet> groups
<xentrac> grep source for regexp "signal *("
<xentrac> acet: sounds good
<acet> xent: that would require those people in the group with you to
<acet> make that information available to you.. it should not be
<acet> standard or expected from anybody.. it's a privacy issue.
<*F'lar*> potatoes?
<ick> /m F'lar yes
<ick> /m F'lar or pastrami
<xentrac> acet: it shouldn't be *required* to register your group
<xentrac> *anywhere*...
<*F'lar*> heh
<ick> i think it should be standard to give out your info, and then you have a choice of withholding info
<xentrac> but it might be *easier*... especially if that were the
<xentrac> default for non-secret groups.
<acet> xent: hrm, we're talking about doing something like /whois
<acet> acet and seeing all the groups I'm in or own?
<xentrac> or you could set it the other way around if you're paranoid or
<xentrac> secretive...
<acet> if you make it standard then you allocated space in the
<acet> display (formatting type concerns) for that information... if
<acet> you don't make it standard, then you have to ask for it or use
<acet> a special command. 
<xentrac> kind of like caller ID *67 *69
<ick> yeah... when you call, i get your info, but you can block it
<xentrac> acet: what?
<xentrac> acet: how about a display for all groups the client knows
<xentrac> about...
<ick> acet: this goes back to "what does the group server know"
<ick> what should it know? i think it should know about all groups and users in them,
<xentrac> acet: which can be restricted by various criteria... like how
<xentrac> many people are in the group (info from either group server or
<xentrac> group-host/client-server itself) and where you learned about
<xentrac> the group from.
<acet> yes, ok, I agree with that... the information should be *able*
<acet> to be made available and it should a user-configured option to
<acet> do so. Ok, now, regarding implimentatation...I think this
<acet> would be a good use for a 
<acet> "data-field" (needs jargon) type thing... somebody can say to
<acet> client that's being inquired "hey, let me see your
<acet> *GroupsI'mAlsoIn field"... client then sends back what it
<acet> thinks is appropriate
<xentrac> ick: it looks like we're coming up with a standard answer for
<xentrac> 'what should X know'...
<ick> xentrac: yes, there hsould be a minimum that X shoudl know, then everything else is extra
<ick> xentrac: one basic is hostname:port
<xentrac> it's this: 'there should be a default to tell X these pieces
<xentrac> of information; this default should be overridable either by
<xentrac> per-occasion or per-person parameters'
<acet> xentrac: yes, said earlier that the client could maintain a
<acet> cache of every group name it's gotten back from servers via /g
<acet> type commands (/g could have filtering qualifiers and etc...
<acet> like /list on irc)... command-line 
<acet> groupname completion would work out of that cache and so on.. 
<xentrac> it'd be nice to have separate windows for commands and
<xentrac> conversation-typing
<acet> ick: I say group servers should know only the barest minimum
<acet> of what they need to know... any extra information will have
<acet> to be provided by the clients or clientservers that
<acet> information is regarding.
<ick> acet: and what do you think are the minimums?
<acet> xent: yeah, was thinking screen-like multi-window interface
<acet> (am defaulting to text-terminal type interface, not X)
<xentrac> hmmm...
<xentrac> acet: yeah, X-type interface can come later if we want
<acet> ick: not sure... but it definatly has no use knowing who is in
<acet> which groups.
<ick> acet: then how would /ms work?
<acet> ick: that's completely optional. 
<acet>  /ms wouldn't travel between client-servers... 
<ick> acet: yeah.. but how owuld you get another users hostname:port?
<acet> client asks group server "who can I send this message to"...
<acet> that's all part of user data, not group data.
<acet> user data registered with groupserver
<ick> oh.. ok.. so the group server knows about grousp and clients but they are not associated with each other
<acet> we've had this conversation before methinks... and I'm not
<acet> sure what we concluded
<ick> (we concluded nothing, we all went to sleep_
<acet> exactly
<ick> so how owuld /w 
<acet> :-)
<ick> work
<xentrac> most of the time, it might be better to ask client-servers
<xentrac> about user's hostname:port
<ick> xentrac: no! clientservers can NOT be trusted
<ick> xentrac: the only trusted machine is the group server
<xentrac> hmmm...
<xentrac> what? why should I trust a group server?
<acet> "data-fields" (really need jargon) in the group data. Group
<acet> can specify a *PeopleInMyGroup field type thingy and client
<acet> can make a "give me all groups with a *PeopleInMyGroup field
<acet> defined and give me the data in that 
<acet> field"... 
<ick> acet: that is lots of data transfering
<acet> xentrac: because you have no reason not to... you control the
<acet> information it contains
<xentrac> acet: how about 'cats' (for categories) for 'ads'?
<acet> clientservers should be taken out of the loop for any task not
<acet> directed at them.
<ick> acet: i like data-feilds
<xentrac> acet: so should group servers.
<acet> blocks? records? hrm, records kinda works
<ick> acet: but records is easier to type
<xentrac> categories for records?
<acet> info-records?
<ick> acet: bingo! i like info-records
<acet> hrm, why not "resources"... ala X?
<ick> i dont like ads/advertisers (sounds like marketing to me, yuck!)
<xentrac> I could have a category in my client for records describing
<xentrac> what groups I'm in.
<acet> using "resources" fits because the analogy to X is the same...
<acet> kinda
<xentrac> acet: 'resources' was one of the terms that always annoyed me.
<xentrac> I like records better than ads too.
<xentrac> acet: 'resources' is incredibly general.
<acet> records? ok
<ick> yay!
<ick> acet: what i meant is that if group server know about what users are in what groups, then it can easier send one list over to client
<acet> #define records :)
<xentrac> :)
<xentrac> I have an interesting idea... tell me what you think
<ick> acet: plus, client does have right to control what happens in his groups-im-in entry
<xentrac> requests for info could be handled analogously to broadcasting
<xentrac> on a group
<acet> ok, hrm, I feel preachy, anyone want to listen?
<ick> yeah.. go for it
<acet> ick: yes. 
<acet> ok, begin sermon:
<acet> a few weeks ago I boiled down the definition of group-servers
<acet> as "databases". That's what they are... people come in, they
<acet> sign-on in order to use the database, and then they deposit
<acet> information and make queries. (cont)
<acet> basicaly, with the use of Records... I see each user and group
<acet> being allocated, on the database (a.k.a. group-server) a
<acet> fixed-size block of memory-like storage space which they can
<acet> fill with whatever information they 
<acet> please, as long as they don't exceed their quota. (cont)
<xentrac> hmmm... me no like
<acet> each record could have a name, like "*GroupsI'mIn" or
<acet> "*OtherPeopleInThisGroup" (just examples for illustration).
<acet> The groupserver understands how the data is formatted (I.e.
<acet> there is a record named "GroupsI'mIn")... but 
<acet> does not neccesarily understand what the data in that field
<acet> represents. (cont(?))
<xentrac> #1: you shouldn't have to sign on to use it.
<acet> afk, hold on xent, I have answers
<xentrac> ah... I like that data-structure.
<xentrac> although I think it would be OK to have a *little* server-side
<xentrac> within-record data structuring... most records consist of
<xentrac> multiple items, like groups.
<ick> know wehre i can get curses info?
<ick> (also, if every machine has curses, how can it be unportable)
<acet> back... I continue:
<xentrac> and it might be nice to have server have an index of all, say,
<xentrac> last names of people... hashed... but clients should be
<xentrac> prepared to do that work too
<xentrac> ick: man curses... it's unportable in that the calls don't
<xentrac> always do the same thing on every OS.
<acet> while the server may not be able to understand what the data
<acet> means in such fields, there can be standard formatting
<acet> conventions agreed upon between clients on how the data within
<acet> that field should be organized. For 
<acet> instance, one could have a 3k field of "PeopleInMyGroup" type
<acet> data, with each name being a null-terminated string. The
<acet> client would ask the server to return the entire contents of
<acet> that field and the client would format 
<acet> accordingly for the user
<xentrac> hmm... it would also be *really* nice to have dynamically
<xentrac> sizable records
<acet> xent: as far as the having to sign on to a database, that is
<acet> simply a mechanism to support authentication. There could
<acet> easily be databases that will accept logins from anybody, even
<acet> if they know them or not. There may 
<acet> be other databases which require a correct username:password
<acet> combination (or a new user) before giving that person access 
<xentrac> say, store the record as a (realloc()able) NULL-terminated
<xentrac> array of pointers to null-terminated strings representing
<xentrac> items within the record.
<xentrac> acet: dandy!
<xentrac> :D
<acet> xent: yes, that's what this idea supports. All the server
<acet> knows is that you have a fixed block of memory (kinda liked
<acet> _DATA) and that you've chopped it up into various records. You
<acet> also define the length of those 
<acet> records since the server doesn't know formatting conventions
<acet> like ASCIIZ strings. In short, users and groups can partition
<acet> their record block however they wish.
<ick> is it just me, or does this semms liek there will be no standard? when i do /w i might end up getting twenty different types of formatted text
<acet> xent: you like?
<xentrac> acet: hmmm...
<xentrac> I like it a lot.
<xentrac> I kind of think that the group server ought to do *some*
<xentrac> higher-level processing...
<ick> yeah, since i know that a clientserver/client running on caffeine would not like to do everything
<acet> this will need database equivalents to malloc() or whatever...
<acet> procedure for setting up information would probably be like
<acet> "allocate record of 521bytes, name it "FooBarInfo" <End of
<acet> Request> <New request> Accept next 
<acet> 521 bytes of data and store it in record "FooBarInfo".
<xentrac> doing higher-level processing would probably reduce everyone's
<xentrac> load...
<acet> ick: clients will eventually come to agree upon the Right
<acet> Format for that information.. there could even be multiple
<acet> formats, identified by an agreed upon 'datatype' flag.
<xentrac> I thought 'records' were individual items... like
<xentrac> 'xentrac:altona.math.unm.edu:5455:Kragen Javier Sittler'
<acet> they are.
<acet> but you have to name those records and define how big they
<acet> are.
<xentrac> acet: eventually, all people will come to agree on the Right
<xentrac> Chat System.
<ick> ok.. this records things sounds good
<xentrac> acet: that means you could have more than one {record} in the
<xentrac> {category} "what groups I'm in"
<ick> how will basic things liek /w group work?
<acet> xent: this enables other people to continue the design of this
<acet> and make tunachat more like the Right Chat System. Our ideas
<acet> aren't the  best in the world most likely... this just lets
<acet> other people try their own ideas.
<acet> category? 
<ick> xentrac: no, you can have more than one "entry" in a record
<acet> I'm just considering {records}.. no categories. 
<xentrac> I think a standard (but not enforced) set of {categories},
<xentrac> with possible multiple {records} in each {category} would be
<xentrac> good.
<xentrac> acet: I have a slightly more structured idea... I think that
<xentrac> more server-side processing would be better.
<acet> ick: /w would be like querying the database for all records of
<acet> the name "PeopleInMyGroup" (clients will have to come to a
<acet> standard on what record name to use for /w commands)
<xentrac> OK... more than one {entry} in a {record}.
<ick> acet: expalin more about /w, i dont get it
<acet> xent: uhm, you can build that upon my idea. Someone can invent
<acet> a descriptive string that lives at the header of a record
<acet> field that says "this block of data is chopped into various
<acet> fields of this type: blah blah blah"
<xentrac> acet: better idea.
[=Change=] phess (phess@shell1.best.com) entered group [NR]
<phess> arg
<acet> ick: don't get it? hrm, ok, define what you think of when you
<acet> think of /w... what does your /w do?
<xentrac> hi phess.
<ick> yhelu
<ick> acet: well, my /w just got destroyed with the idea that clients are not associated with groups in the database
<xentrac> I think I have a better idea... give me that pulpit for a
<xentrac> moment, eh? :)
<acet> xentrac: "better idea" == "I have a better idea than that" or
<acet> "yes, that idea is better"?
<xentrac> the server should know about records and entries.
<phess> sometimes i thnk i ougghta just nuke them all...  every
<phess> dumbshit user i have ever come across...
<ick> phess: then who would you ever make off of?
<acet> ick: /w exists and it exists strongly... needs no kludges to
<acet> impliment, will explain it to you (later, let xent speak)
<xentrac> both clients and clientservers should be able to make entries.
<ick> phess: make money/enojyment laughing at
<xentrac> not entries, but areas.
<xentrac> you should put (say) your nick, your hostname, your port, etc.
<xentrac> in your area, as one item in a record called 'person' or
<xentrac> something.
<acet> xent: hrm, You lost me.. I thought that's exactly what they
<acet> could do... 
<acet> (will wait till you're finished, xent, sorry)
<phess> ick: there are lots of people dumber than me.  i could
<phess> laugh/make money off them.
<ick> /m phess exactly, so dont nuke them
<xentrac> server should be able to do things like send all the items in
<xentrac> such-and-such a record of a list of areas... areas
<xentrac> corresponding to clients, client-servers, or maybe even
<xentrac> group-servers.
<*phess*> i only wanna nuke the ones that are calling me. thats all.
<ick> /m phess oh.. ok.. go ahead.. but please do it no i am not affected :] (a.k.a. not in abq)
<xentrac> There's some information that's best kept on the
<xentrac> group-server... information people are likely to want to get
<xentrac> in bulk, or search through.
<acet> xentrac: (sorry if interrupting) You mean something like
<acet> *Person.Name: "blah blah"; *Person.Email: "foo@deepthought"; ?
<acet> kinda like X resource strings?
<xentrac> there's some information that's best kept on
<xentrac> client-servers--that information that's likely to be of
<xentrac> interest mostly to people who are either in the group or want
<xentrac> to be.
<acet> .. then people can make requests like "Send me Person.*"
<*phess*> the 3 calls i have had from ABQ were ok...
<xentrac> acet: hmmm... perhaps...
<ick> acet: i like that
<ick> acet: then groups can also have fields, and one can be Group.members
<phess> ick.
<xentrac> there's some information that's best kept on clients
<xentrac> themselves-- that information that's likely to be of interest
<xentrac> if you know the client's user.
<ick> phess.
<ick> /m phess have you heard of some chat program being desgined here on icb (not ours)?
<acet> xent: was thinking that clientservers would indeed hold this
<acet> information and it will be their responsibility to keep that
<acet> information updated and fresh on group-servers if they want
<acet> people to be able to access accurate 
<acet> and up-to-the-minute information
<xentrac> ick: you could do it that way... but unless you think it's
<xentrac> reasonable for people to search through all the people who
<xentrac> belong to gropu
<xentrac> ups, then why keep that on the server?
<xentrac> acet: which information?
<acet> xentrac: information like the list of people currently in the
<acet> group, the name of the moderator, etc etc etc.
<ick> acet: i love that idea! its waht i have wanted since the begining
<*phess*> newp. sure havent.
<xentrac> what's the reason for keeping that on the group-server?
<ick> xentrac: so peopel can gab a big chunk of info
<acet> are you suggesting that there should be a way to make
<acet> record-requests to the client-server as well?
<ick> acet: if client-servers have resources, then they can keep there Group.members updated and thats how we can do /w :]
<*phess*> im kinda designing one here (at/for work)
<xentrac> acet: yes... after all, the client-server has to *maintain*
<xentrac> that information, ne?
<xentrac> ick: like, who's in a large number of groups?
<acet> you only put info on the group-server that you think is
<acet> appropriate for people making queries on that group-server to
<acet> see... 
<ick> /m phess is it really big? or <= size of icb?
<xentrac> ick: as long as we're sending requests and so forth via UDP,
<xentrac> it'd be more efficient to just ask all the groups for that
<xentrac> information... unless it's information that should be hashed
<xentrac> and indexed.
<acet> hrm, xent: need to distinguish between requests to the
<acet> client.server and requests to the group.server
<*phess*> i dunno what the size of icb is. has very similar
<*phess*> functionalities. right now, im just designing the data
<*phess*> structures
<xentrac> acet: I think there are two excuses for having a group-server
<xentrac> at all.
<ick> /m phess oh.. ok... icb is about 100 users and 4 servers that are not connected
<acet> ick: exactly! that's what I was thinking of
<xentrac> ick, acet: I agree with that idea.
<ick> acet: geeez, and all this time i thought that we had totally different ideas
<xentrac> 1) locate people 2) query databases
<xentrac> not 'people'... 'points'
[=Change=] Suzanne (suzdev@carina.unm.edu) entered group [NR]
<xentrac> hi suzanne.
<ick> helu    
<Suzanne> why is all the stuff on my screen written with white
<Suzanne> background?
<acet> xent: if you're suggesting that the client-server act as a
<acet> sort of secondary cache for requests going to the
<acet> group.server... I'm not sure that can work
<Suzanne> little white squares and rectangles of words
<xentrac> I don't think there's really any reason to ask a group-server
<xentrac> for information on a *specific* point, other than to find out
<xentrac> how to contact that point.
<Suzanne> ITS VERY ANNOYING
<ick> xentrac: no!
<xentrac> suzanne: dunno. you got an escape sequence
<ick> xentrac: sgroup servers are meant to be run on fast connection machines
<ick> xentrac: caffiene can not afford many queries
<Suzanne> hmm
<Suzanne> okay thanks
<Suzanne> bye
[=Change=] Suzanne (suzdev@carina.unm.edu) just left
<ick> xentrac: but no one shoudl have to loose my information just because i can not maintain it
<xentrac> acet: no, I think the kinds of requests you should make of the
<xentrac> group server should be conceptually different from the
<xentrac> requests you should make of he 
<xentrac> the client server.
<acet> xentrac: I think the idea of having the client-server serving
<acet> as a convienent proxy between communications between the
<acet> client and group-server is highly dangerous... that puts more
<acet> trust in the client-server than I 
<acet> like, even if it is more efficient
<ick> yes... unless the clientserver should know baout the transfer, it should not be used as a router
<xentrac> acet: when did I talk about CS acting as proxy for GS?
<acet> xentrac: I thought that is what you were saying... give me
<acet> examples of CS info and GS info.
<ick> xentrac: CS has to do everything a GS can, except for multiple groups
<xentrac> ick: what information about yourself would you be unable to
<xentrac> maintain
<ick> xentrac: who is in my group, who is moderator, who is this, who is that... so on, i am an expection, suzanne is not (she is at 2400bps)
<xentrac> acet: GS info is:
<acet> ick: eh?
<xentrac> 1) things that allow you to get in contact with a particular
<xentrac> point
<xentrac> 2) things that you'd want to search through... likew
<xentrac> kue
<xentrac> like people's names
<ick> acet: nevermind, i said it wrong
<acet> CS info?
<ick> acet: people in that group, who are moderators, whos manager, whos vice manager
<xentrac> client server knows GS stuff... although maybe it doesn't do
<xentrac> searches
<xentrac> also, maybe a group charter...
<ick> those are all thing that can be in CS info
<xentrac> things of relevance to the group itself
<acet> if client server knows GS stuff, why go to the GS? Is that
<acet> what you mean?
<ick> it knows GS stuff!?
<xentrac> and things of interest to the members, or likely members, of
<xentrac> the group
<xentrac> it knows GS-*type*s
<xentrac>  stuff.
<xentrac> it doesn't have to know about *all* groups or users... but it
<xentrac> would be nice to have a provision for it to know *something*
<xentrac> no no no
<acet> ok, I think I'm getting idea of what is meant... seperation
<acet> between CS and GS info... this allows the CS to make available
<acet> information that people only using the GS will be unable to
<acet> see... like who are moderators, 
<acet> managers and etc... for this to work there needs to be a
<acet> seperate mechanism for making queries to the CS and making
<acet> queries to the GS
<xentrac> acet: I think the same *kind* of database and queries would
<xentrac> work... although maybe with searches disabled
<ick> stop! i found bug in icb.. i think
<ick> when xentrac said nonono, xentrac: was that a resopnse to acets message?
<xentrac> btw... I think that if you want to know what groups a *person*
<xentrac> is in, you should ask their client, not a group server.
<*TCA*> Hi.
<acet> yeah, I think the idea of a CS database could be snazzy...
<acet> but, as I said, there needs to be a distinctly different
<acet> mechanism for making queries to the CS compared with making
<acet> queries to the GS
<*TCA*> What would it take for me to get a cracked version of either
<*TCA*> Topas or 3DS?
<acet> xentrac: I think if you want to know what groups a person is
<acet> in, you should ask the group server to see if the person
<acet> registered on that system has defined a "groupsI'mIn" field. 
<xentrac> that was a response to 'is that what you mean? why go to the
<xentrac> GS?'
<ick> oh.. ok.. nevermind, no bug
<ick> /m TCA a trip to cec and an account on pyr0, they are such horrible sysadmins, that the crack is still on that hard drive
<acet> don't bug their client...the database is a convienent dumping
<acet> ground for people to place information so other people don't
<acet> have to go directly to them to get it. That's it's purpose... 
<xentrac> acet: I think that's information you're unlikely to want to
<xentrac> search by... and if you do, there are better ways (like asking
<xentrac> the clientservers) which are more efficient.
<acet> this still gives the client's control on how much the group
<acet> server knows about htem
<*TCA*> For topas?
<ick> /m TCA yup
<*TCA*> or 3DS, or both?
<ick> /m TCA i know someone who has 3ds2 cracked good
<xentrac> acet: why would it be better to bug group-server than to bug
<xentrac> their client?  group server has to handle requests for
<xentrac> information about thousands of people... why give it more
<xentrac> work?
<ick> because machines like caffeine when ftping are slowed down to very low trasfer rates, and i dont wnat to hurt my ftp transfer rates
<xentrac> client only has to handle requests for information about *one*
<xentrac> person.
<acet> xentrac: ugh, methinks you've gotten out of sync... 
<ick> xentraC: group server handles jobs for thousands of people... so let it contuinue doing its job
<xentrac> only reason I can see to place information in GS database is
<xentrac> so people can search on it... I might want to put my full name
<xentrac> and email address there, for example, so that people can
<xentrac> search for me by them.
<ick> exactly
<ick> now what info would you be asking the clientserver?
<xentrac> hmmm... I just want things to be as decentralized as possible.
<ick> xentrac: but not by adding unnecessary winkys
<xentrac> that way, no particular net link will be mega-saturated,
<xentrac> leading to no lost packets.
<xentrac> the clientserver?
<xentrac> a) 
<xentrac> information about the group... maybe text documents
<acet> hrm, xentrac: problem... ok? Say you want to know what groups
<acet> acet is in... no problem, connect to acet's client. Wait,
<acet> who's acet? Do you mean the acet as defined on
<acet> groupserver:moonshine or the acet as defined on 
<acet> groupserver:shineymoo? Which client do you connect to? 
<*Surface*> HEhheHHEh
<ick> /m Surface what?
<xentrac> acet: that's a problem no matter what you do... it has to do
<xentrac> with nick policy. ick & I have discussed a little... let's
<xentrac> talk a little later
[=Topic=] ick changed the topic to "Tiny childern are like potatos"
[=Topic=] ick changed the topic to "DontPutURHandWhereUWantURFace"
<xentrac> ick: unnecessary winkys? which?
<ick> xent: things like asking clients questions
<acet> waitaminute: ok, fast elegant solution for groupsI'mIn
<acet> implimentation. Remember resource strings? Fine, define the
<acet> following strings: "GroupsI'mIn.m0o" "GroupsI'mIn.ishiboo"
<acet> "GroupsI'mIn.guacamole"... now, to find out 
<acet> what groups someone is in, ask the server for "GroupsI'mIn.*"
<*Surface*> nothing. can you steal a top-of-the-line sgi workstation?
<ick> /m Surface no
<ick> /m Surface you can tho
<xentrac> b) who's in the group, and how to contact them (presumably,
<xentrac> this means that if gorg says something, you can ask
<xentrac> clientserver who gorg is (automatically) in order to /m him
<xentrac> about it...
<*Surface*> j/k. and no i cant
<ick> xentac: why not let GS have CS field like Group.members
<xentrac> ick: client includes clientserver code, right? and
<xentrac> clientserver code has to anser
<xentrac> questions anyway?
<ick> xentrac: no! thats different, when i am client, i expect no lag other than from cleint server and whispers
<xentrac> seems like it's just a matter of making sure that the database
<xentrac> you answer questions out of isn't declared globally.
<ick> acet: good idead
<acet> xent: got problem in there about who gorg is. Do you mean the
<acet> gorg that's in the group with you, or the gorg that's defined
<acet> on groupserver:foobar... hrm, or is that the problem you're
<acet> talking about?
<xentrac> ick: because, if you want to search on a particular group
<xentrac> member or members, you should do it through their clients...
<xentrac> if their clients want to let you... and if you want to know
<xentrac> who's in the group, you should ask group
<ick> i like acets idea much better, that way i can jsut send GS info whenever i join new groups and leave odl groups, and you can just ask it, not me
<xentrac> ick: unless someone's flooding you with requests (in which
<xentrac> case you start ignoring them) there will be no lag.
<ick> xentac: but why do it at all? let the GS do its job... hold info
<acet> yah
<xentrac> acet: who gorg is, according to clientserver, is same gorg who
<xentrac> is talking in clientserver group.  so if you want to /m *that*
<xentrac> gorg, it's best to ask clientserver...that gorg might be
<xentrac> registered under some otherNickOnGS
[=Sign-on=] synk (synk@thelair.zynet.com) just joined
[=Notify-On=] synk (SYNK@THELAIR.ZYNET.COM) just signed on
<ick> helu
<acet> ick: however, there is problem with the "which acet is the
<acet> acet that is in the group with me right now"... there can be
<acet> multiple acets, one per group-server, remember? 
<synk> lo
<ick> hmmmmm
<ick> ok... how baout default acet is always acet on your own GS, but you can say acet@shinymoo
<xentrac> there could also be one acet per group
<ick> xentrac: that i dont like
<synk> in my implementation there could only be one acet per group
<synk> but lots of acets so you could do /m acet@ishiboo
<acet> ick: remember, you can be simultaneously connected to and
<acet> serviced by multiple GS's.
<xentrac> ick: I think we should limit GS info to info which is more
<xentrac> useful on GS than elsewhere.  Mostly that means info about
<xentrac> well-defined place.
<ick> acet: hmmm, how about being able to specify a default acet
<xentrac> not about well-defined place. info located in well-defined
<xentrac> place.
<ick> like /m acet blah, will ask you which acet?
<acet> ick: bad idea
<xentrac> ick: good idea
<acet> good idea? 
<ick> hehe
<ick> that was funny, i was expecting two bad ideas
<acet> methinks if you do /m acet, it will default to the acet that's
<acet> in the group with you, if any... if there isn't an acet in the
<acet> group with you, it goes off to ask group servers.
<synk> ick: bad idea
<synk> there ya go :-)
<acet> synk: hehe
<acet> h
<xentrac> let's argue about nick policy later...
<ick> fine with me, i am still stuck on curses
<acet> xent: you brought up a very legit problem... I'm not sure how
<acet> to solve it either
<xentrac> I want to talk about division of labor between GS, CS, and
<xentrac> client
<xentrac> I think information should be located at the most
<xentrac> decentralized possible location without sacrificing utility.
<synk> afk checking pizza
<acet> I have no problem with centralizing information as long as the
<acet> centralization is a convinence and the users decide for
<acet> themselves who they go to hold their information for them.
<xentrac> for finding out where people or groups are, or getting a list
<xentrac> of groups with between 15 and 50 people, that mostly means GS
<acet> yeah
<ick> acet: yeah
<xentrac> 'convenience'?  who are we inconveniencing... the
<xentrac> get_user_info() subroutine?!
<acet> calm down xent, what are you talking about?
<xentrac> or maybe it's the extra 200 ms of lag before we find out what
<xentrac> groups a person's in?
<acet> I was just stating a basic attitude.
<xentrac> *calms*
<xentrac> *breathes deeply*
<xentrac> :)
<ick> xentrac: werhe are you?
<xentrac> at ESC N
<ick> xentrac: are toher poeple looking at you strangly?
<xentrac> I don't think where you locate information affects its
<xentrac> convenience, as long as there are well-defined ways of
<xentrac> locating it which are fast.
<xentrac> no... I didn't breathe *that* deeply :)
<xentrac> wait... let me amend that statement.
<acet> *waits*
<xentrac> if there are well-defined ways of locating it that are fast,
<xentrac> *and if you likely want information which can be gotten from
<xentrac> one or a few places*... like the groups a person's in.
<xentrac> sorry so slow.
<xentrac> if you want to *search* through information, central location
<xentrac> is beneficial.
<xentrac> and if you want to find out where to get information, there
<xentrac> should probably be *some* big repositories of data about where
<xentrac> to get information... but I'd rather have an archie gateway on
<xentrac> the WWW than a huge FTP archive
<xentrac> I'd better go.
<xentrac> bus is leaving.
<ick> guby