groupkit-users Mailing List for GroupKit
Brought to you by:
cthatcher,
markroseman
Menu
▾
▴
groupkit-users — GroupKit Users and Developers
You can subscribe to this list here.
| 2003 |
Jan
(1) |
Feb
(1) |
Mar
(4) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(2) |
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: cheque539 <che...@ho...> - 2008-02-09 18:05:37
|
Hi lista, cheque539 thinks you would enjoy our community. You can find the best in world cinema, watch it on your computer or television, and discuss it with people who love movies as much as you do. I joined Jaman.com for their great movies, and I think you should too. You can watch any three movies you want on Jaman. Enjoy! If you use this link, cheque539 will know you accepted the invitation: https://www.jaman.com/a/register/?it=0B_yOtC8jS4s Hope to see you on our site very soon, The Jaman Team Jaman : 2955 Campus Dr, Suite 250, San Mateo, California 94403 If you do not wish to continue receiving emails, please change your notification preferences : http://www.jaman.com/a/unsubscribe/0q4-sEsFX0IQ/?uM=Z3JvdXBraXQtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0 Privacy Policy: http://www.jaman.com/a/download/?theAction=show_privacy_policy |
|
From: <con...@ce...> - 2007-02-19 19:04:43
|
> I then click OK and a window pops up with > the following error: > Fatal Error in Wish - alloc:invalid bloc: 00C22DC8: ef ff 35 This bug is fixed in the CVS. Mark, if you still listen to this mailing list, would it be possible =20 to do a release with the current CVS, so that windows users, =20 or .tar.gz users benefit from the last fixes ? best regards, s. -- St=E9phane Conversy Ecole Nationale de l'Aviation Civile, Toulouse, France http://www.tls.cena.fr/~conversy enac: +33 5 62 17 40 19 dgac r&d: +33 5 62 25 96 48 |
|
From: Jesse V. <jes...@gm...> - 2007-01-28 19:46:07
|
I am unable to get groupkit 5.2 to run on a PC with Windows XP, media center edition, running ActiveTCL 8.4.14.0. Here's is what is happening: 1. I run the registar.tcl program. It runs, but does not prompt me for anything. I am able to verify that the process wish84.exe is running. 2. I run the openreg.tcl program. Here I am prompted with a window. I blank out the default domain name. The host is set to "MACHINE" so I change that to 'Jesse', which is what my machine is named. I then hit return or OK, and I am prompted with a 2nd window "Connect to GroupKit registrar located on... ". I leave the Port number as 9357 and I change host name to 'Jesse'. I then click OK and a window pops up with the following error: Fatal Error in Wish - alloc:invalid bloc: 00C22DC8: ef ff 35 I also get this error when I specify my actual IP address as the host. Any thoughts on how to fix this? I've experminted with specifying 'localhost' instead of 'Jesse' and changing the port number, but in all these cases I get a different error like "Could not connect to registrar at localhost:9357. Couldn't open socket: connection refused." Thanks VERY MUCH in advance for any suggestions. |
|
From: alvaro h. <che...@ho...> - 2005-08-04 19:03:17
|
<html><div style='background-color:'><DIV class=RTE> <P><BR><BR></P><BR><BR><BR>>From: "hanoi guillermo Bautista" <ha...@ho...><BR>>To: el...@ho..., pa...@ho..., chi...@ho..., che...@ho..., man...@ho..., irm...@ho..., iva...@ho..., mar...@ho...<BR>>Subject: FW: RV: renvialo xfavor..<BR>>Date: Wed, 03 Aug 2005 19:05:48 +0000<BR>><BR>><< text2.html >><BR>><< text2.html >><BR>><< text2.html >><BR>><< text2.html >><BR>><< text2.html >><BR>><< text2.html >><BR>><< text2.html >><BR>><< text2.html >><BR>><< text2.html >><BR>><< text2.html >><BR>><< text2.html >><BR>><< text2.html >><BR>><< text2.html >><BR>><< text2.html >><BR>><< text2.html >><BR>><< text2.html >><BR>><< text2.html >><BR>><< pic15660.gif >><BR>><< pic08127.gif >><BR>><< YuridiaJaquelineEscobar.JPG >><BR></DIV></div></html> |
|
From: Mark R. <ma...@ma...> - 2005-06-08 20:01:17
|
You may have heard of a project called Tequila that Jean-Claude Wippler had done a few years ago, which provided a mechanism to share data using automatically synchronized Tcl arrays. As part of a larger project, Jean-Claude has been doing a major revamp of Tequila. He's borrowed a lot of core concepts from GroupKit, giving the new version (called T2) familiar remote procedure calls, events/ notifiers, and pools, which are like GroupKit environments, but built on Metakit tables. The latter is a distinct improvement, providing a more natural way to structure the kind of data often used in collaborative apps. It also means its naturally persistent. The whole thing was designed from the start to work with Starkits, meaning deployment is a snap. T2 is much leaner, more like the older versions of GroupKit (without all the collaborative UI layer) than when we started mucking around with the meta-architecture stuff. It's not focused specifically on user interface oriented collaborative apps (though it can do them nicely), but data sharing more generally. There are some big additions planned; right now its in the state of having the basics and a few demos in place, and trying to get the core API's right. As such, it's a great time for feedback from some people who are interested in this kind of system, or would like to get involved. Hence this email. There's info on Tequila at http://www.equi4.com/tequila.html In particular, take a look at the paper, slides and the Starkit referenced in the "Latest News" section of that page. Hope you all find this of interest. Cheers Mark |
|
From: alvaro h. <che...@ho...> - 2004-10-21 13:46:55
|
<html><div style='background-color:'><DIV class=RTE> <P><BR><BR></P></DIV> <DIV></DIV>>From: "Vania Vazquez" <van...@ho...> <DIV></DIV>>To: ae...@ho... <DIV></DIV>>Subject: FW: Porque tener novio (a) <DIV></DIV>>Date: Mon, 18 Oct 2004 08:40:59 -0500 <DIV></DIV>> <DIV></DIV></div><br clear=all><hr>T1msn Fotos: Todo lo que quieres saber sobre fotografía digital <a href="http://g.msn.com/8HMAESMX/2749??PS=47575" target="_top">Haz clic aquí </a> </html> |
|
From: Alvaro H. <che...@ho...> - 2004-09-01 03:46:06
|
Hi, I am creating a birthday calendar of all my friends and family. Can you please click on the link below to enter your birthday for me. http://www.BirthdayAlarm.com/dob1/23575523a725731389b182946732c904 Thanks, Alvaro |
|
From: <aku...@sh...> - 2004-08-20 03:05:11
|
11'th Annual Tcl/Tk Conference
October 11 - 15, 2004
New Orleans, Louisiana, USA
Email Contact tc...@tc...
We are pleased to announce the 11'th Annual Tcl/Tk conference
(Tcl'2004), sponsored by Noumena Corporation, in cooperation with
ActiveState and ExpoTech.
Come to New Orleans to:
* Learn about the power of Tcl/Tk.
* Present exciting new work involving Tcl/Tk.
* See the latest developments in Tcl/Tk.
* Meet Tcl/Tk researchers and users from academia, government and industry.
* Plan for future Tcl/Tk related developments.
The conference program will include paper presentations,
tutorials, Birds of a Feather (BOF) sessions and invited key-note
talks.
Registration
Online registration is ready now.
<http://www.tcl.tk/community/tcl2004/reg.html>
Tutorials
Come learn about Tcl from the experts. This year's Tcl/Tk
Conference includes one of the best sets of Tutorials ever offered
including tutorials on Jacl, TclHttpd,
Starkit, Advanced GUI construction, and the API.
<http://www.tcl.tk/community/tcl2004/tut2004.html>
Schedule
More details will be added to the schedule as they become
available.
<http://www.tcl.tk/community/tcl2004/schedule.html>
Those attending the conference will be interested in the
conference info page.
<http://www.tcl.tk/community/tcl2004/info.html>
To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list.
<http://listserv.activestate.com/mailman/mysubs?show=announce>
Other Forms of Participation
For those who are not presenting a paper at the conference, but
would like to present their work in some form, we do provide
several other forms of participation.
Slots for Works-in-Progress (WIP) presentations and
Birds-of-a-Feather sessions (BOFs) are available on a first-come,
first-served basis by sending email to tc...@tc.... Some WIP
and BOF time slots will be held open for on-site reservation, so
we encourage all attendees with interesting work in progress to
consider presenting that work at the conference.
Conference Committee
Gerald Lester HMS Software General Chair
Andreas Kupries ActiveState Corp
Clif Flynt Noumena Corp Website Admin
Jeffrey Hobbs ActiveState Corp
Kevin Kenny GE Global Research Center
Ken Jones Avia Training
Mac Cody Raytheon Company
Kim Richerts
Steve Landers Digital Smarties
Sheila Miguez Motorola
Larry Virden Tcl FAQ Maintainer
Contact Information
tc...@tc...
|
|
From: Venkata P. C. <vc...@ua...> - 2004-08-05 17:31:06
|
confirm 744845 |
|
From: <ben...@id...> - 2004-05-22 12:04:14
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: alvaro h. <che...@ho...> - 2004-05-03 17:44:47
|
<html><div style='background-color:'><DIV class=RTE> <P>Hi... sorrry for my bad English... My name is Alvarito Hernandez, I'm from Oaxaca, Mexico. Actually I'm studying Computing. I'm interested in to develop a voice or video communication module for GroupKit project. <BR>I'm beginning, so can you give some advice or any suggestion about this idea....Thanks a lot... </P></DIV></div><br clear=all><hr>MSN. Más Útil Cada Día <a href="http://g.msn.com/8HMBESMX/2740??PS=">Haz clic aquí. </a> 2 months FREE* </html> |
|
From: Aaron C. <aar...@ya...> - 2004-04-02 19:27:53
|
Well, we're still discussing what project we want to/are able to work on, but I'd be happy to share our project and some of the stuff we discovered while using groupkit. If you'd like, I can post a tar ball of the project, and even the paper about our project (or at least the pertinent parts), to a web site. But yeah, it would be a fun to dig into this after having used it and learning some of the caveats. Plus (and good to us) we wouldn't have to try to figure out a whole other language and toolkit! Oh, yeah, what we did with toolkit was make a game of memory that you share with others (taking turns). The idea was to use it as an "Icebreaker" in residence halls by matching a person's face to name and getting people to discuss who is who and remember which cards match up. It was fun. Anyway... ~Aaron > From: Mark Roseman <ma...@ma...> > Subject: Re: [Groupkit-users] something to do > Date: Thu, 1 Apr 2004 11:24:14 -0500 > To: gro...@li... > > Hi Aaron, > > Cool! I didn't know of anyone who was still using > GroupKit > for their coursework etc. How did your project go? > Any > thing to share? > > I assume you've had a chance to browse through the > wiki > at http://tcl.projectforum.com/groupkit/ ... while > some of the > suggestions there are pretty major undertakings, > there's > certainly some smaller pieces (aqua port, > starkit-ifying for > easier distribution, etc.) that would be cool. Of > course, the > best thing is if there was anything that frustrated > you a bit > or that you found missing when you were working on > your > previous project. > > There hasn't been any active work on the GK core in > a while, > but a few people are still using it (and there's a > few things > that I'd still like to do with it one day) and I'm > sure any changes > would be appreciated. Let me know if you have > questions etc. > > Mark > > > > On Mar 31, 2004, at 9:33 PM, Aaron Christensen > wrote: > > Hi, my group and I working on a project for a > class on > > CSCW at the University of Minnesota. We just got > done > > working on a project that used tcl/tk and > groupkit, > > and we thought I fun project would be to update > > groupkit in some way. I was wondering, then, if > there > > is anything we could do? I was looking over some > of > > the stuff for version 6, and right now it seems a > > little beyond me, but we'd be happy to take a > crack at > > it (especially with some pointers ;)). So, yeah, > is > > there anything we can do? > > > > > --__--__-- > > _______________________________________________ > Groupkit-users mailing list > Gro...@li... > https://lists.sourceforge.net/lists/listinfo/groupkit-users > > > End of Groupkit-users Digest __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ |
|
From: Mark R. <ma...@ma...> - 2004-04-01 16:24:20
|
Hi Aaron, Cool! I didn't know of anyone who was still using GroupKit for their coursework etc. How did your project go? Any thing to share? I assume you've had a chance to browse through the wiki at http://tcl.projectforum.com/groupkit/ ... while some of the suggestions there are pretty major undertakings, there's certainly some smaller pieces (aqua port, starkit-ifying for easier distribution, etc.) that would be cool. Of course, the best thing is if there was anything that frustrated you a bit or that you found missing when you were working on your previous project. There hasn't been any active work on the GK core in a while, but a few people are still using it (and there's a few things that I'd still like to do with it one day) and I'm sure any changes would be appreciated. Let me know if you have questions etc. Mark On Mar 31, 2004, at 9:33 PM, Aaron Christensen wrote: > Hi, my group and I working on a project for a class on > CSCW at the University of Minnesota. We just got done > working on a project that used tcl/tk and groupkit, > and we thought I fun project would be to update > groupkit in some way. I was wondering, then, if there > is anything we could do? I was looking over some of > the stuff for version 6, and right now it seems a > little beyond me, but we'd be happy to take a crack at > it (especially with some pointers ;)). So, yeah, is > there anything we can do? |
|
From: Aaron C. <aar...@ya...> - 2004-04-01 02:33:29
|
Hi, my group and I working on a project for a class on CSCW at the University of Minnesota. We just got done working on a project that used tcl/tk and groupkit, and we thought I fun project would be to update groupkit in some way. I was wondering, then, if there is anything we could do? I was looking over some of the stuff for version 6, and right now it seems a little beyond me, but we'd be happy to take a crack at it (especially with some pointers ;)). So, yeah, is there anything we can do? ~Aaron Christensen __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html |
|
From: William D. <wi...@ds...> - 2003-07-24 00:26:01
|
Greetings, I'm interested in using Groupkit as a part of a regression-testing suite. Since Groupkit is tracking screen activity for us already, it should be easier to record and play back those activities. Also, I like the idea that if a script has problems, I can run it again in a little window that several remote people can watch and discuss. A stickier issue is making the playback more on the widget level than on the level of mere x/y screen locations. In other words, instead of saying "move mouse to 323,445 and press button 1", the playback script would say "activate button .frame1.button1". This would go a long way towards helping make the playback scripts less vulnerable to being broken by minor changes to the program or running environment. That may seem like an obscure issue with regard to remote collaboration, but really it ties into the idea of cutting down on the amount of information that needs to be transmitted between multiple remote collaborators. We don't need to transmit every pixel color because both the local and remote machine share a function that can translate a shorter message into the same effective result (e.g. both sides keep a cache of the previous screen). Now extend that same idea a little, and imagine that both the local and remote user were running the same application inside identical "sandboxes" on each machine -- let's say a tcl applet inside a "safe" interpreter. As long as both applications are kept completely in sync, I don't need to transmit a crudely-compressed bitmap of the screen area affected by that application. All I need to do is transmit enough information to keep both copies of the application in sync. In other words, instead of having a button flash, and then transmitting a compressed image of the flash, all I need to do is recognize that button .frame1.button1 was pressed, and send that information to the copy of the application on the remote machine. The point is that there's a connection between remote collaboration and script-driven regression testing. In both cases, we want to distill out the information that matters (this button was pressed), throwing away information that we decide does not matter (the *exact* path the mouse took while moving towards the button). In both cases, it seems like there's promise in approaching the issue from the viewpoint of 1) creating functions that rely entirely on a well-defined state vector, 2) giving all the collaborators a copy of the functions and initial state vectors, and then 3) keeping the state vectors in sync between all the collaborators, so that the functions can generate the detailed results locally. This would even allow people who joined late to catch up with everyone else, since all we have to do is give them the complete state vector -- which is easy to do for a tcl safe interp. Obviously this requires applications that cooperate to some extent with groupkit, but we can still fall back on screen-scraping when all else fails. Also tcl is very good at introspection, so for any given pure tcl/tk application, it may be pretty easy to convince it to work with Groupkit with regard to transmitting state vectors, etc. Has anyone else tried or thought about this sort of thing with regard to Groupkit? Or at the least, has anyone tried using Groupkit in its present form for things like regression testing? --Will William L. Dye |
|
From: Mark R. <ma...@ma...> - 2003-06-27 15:06:48
|
I've taken the liberty of moving the GroupKit ProjectForum site that I had previously set up on my home server machine to a recently setup server used for various CourseForum/ProjectForum sites. The new site is located at http://tcl.projectforum.com/groupkit/ Mark http://www.markroseman.com |
|
From: Mark R. <ma...@ma...> - 2003-04-21 20:13:45
|
Colin et. al., I've also been preoccupied with other things the last while, so haven't really looked much at GroupKit lately. I checked in a fix to the bug you reported (buffer size in rpc code). BTW, if anyone else wants commit access to CVS, please just ask! Availability of GroupKit on Windows is important, so I wouldn't want to include dependencies on packages that weren't available on that platform (ditto Mac OS X, I want to get things running well there under Aqua soon). I think (short term at least) most of the persistence will be of the load-unload environment variety... so any simple database mapping will work. Metakit is appealing because of its platform-support, embeddability, and the fact that I've got tons of other code that relies on it, that I might someday want to integrate with some real-time stuff. ;-) Mark |
|
From: Colin M. <co...@ch...> - 2003-04-21 06:22:29
|
On Wed, 2003-04-09 at 19:35, TongMei wrote: > Hi all, > > Sorry I have been underground for the last month. Had a lot on and have > been totally occupied reading through two p2p books and a few other > books related to open source, databases, distribution etc. Yep, that's cool. I'm similarly intermittant. Someone might commit the sf changes to fix the showstopper bug in the CVS version, though, otherwise people might get the wrong idea re groupkit. > Answering some of the questions raised by Colin McCormack: > > Both encryption and compression will eventually become important > concepts to Groupkit, both for very different reasons and I hope that > together we can implement these simple but powerful layers. The point > raised about the native implementation of sockets (as opposed to using > comm) may also have sway here The more I look at comm, the less enamoured of it I become - it has some spooky almost-OO approaches to creating new channels. > and I have looked at the source code for > simple compression - from the tcl zlib implementation. The packages Trf > and Tls would provide a very strong solution for encryption but we would > then be dependant on those packages. Only if the user wanted to have encryption - I like the idea of using existing modules wherever possible. Mind you, the certificate overhead of SSL is great - the operational overhead of creating the certificates, I mean. Additionally it creates a dependance on the SSLeay package, which AFAIK is not available for Windows (if that matters.) I wrote a Q&D RSA package over my libgmp multi-precision int interface, which when coupled with Trf would give strong encryption and authentication. Of course, it only moves the dependency problem to a lower level, since libgmp isn't easily available for Windows either (if it matters.) > None-the-less I am still in the > process of looking at a great deal of other things and have yet to come > to terms with the socket code in gk. The socket code is funky in a nice way - quite a powerful mechanism. > Metakit databases and persistence are the things I am currently looking > into and would be glad of any help and ideas. I wrote and use a metakit automagic persistence class for itcl, and (coincidentally) use it to store trees (in the tcllib sense of ::struct::tree) I found that there's a mismatch between how ::struct::tree stores, and the preferred storage model for metakit. I guess, since environments (which are tree-structured) are the fundamental structure in groupkit, the question of optimal storage for persistence needs addressing. I guess one'd serialise a gk environment by trying to store it in a single table, with the path expression as the key. It might be efficient, in this case, to store the Mk record number explicitly in the tree, since I can't imagine searching for full path expressions would be very efficient. Additionally, in the vein of looking for code to utilise, and given that trees are special cases of digraphs - is it worth looking at Jacob Levy's e4graph for the fundamental storage mechanism? It's C++, it provides persistence: http://sourceforge.net/projects/e4graph/ It's been a couple of weeks since I looked at the environment implementation, but I recall wondering a couple of things: (a) does the functionality of environment warrant a C implementation (I'm not sure, it well might), (b) does the C implementation of environment warrant a Tcl_Obj wrapper? (I'm not sure of the real advantages, but am happy to run one up) > I had implemented a shody > environment with Mk connectivity but I was not happy with the model and > could already see terrible issues arrising with regards to uniqueness, > freshness and collision. Yes. Mk may not be a good storage model, since it loses the virtues of tree structure inherent in environment - for example one could imagine fine-grained branch-level locking for update, rather than table-level. > So I stopped and decided to read the material > mentioned above. I'm good mates with Matthew Toseland, who's doing some work on one of the P2P things - I'm sure I could ask him to consult if this would help. > I now have a clearer idea of how this may be > implemented but it really does all boil down to one thing: What is our > motivation for db connectivity in Gk? > Is it that we just want the > ability to load data from previous sessions for persistence, or do we > want full blown database support in this environment. The answer to > that question will have significant impact on how we proceed. It troubles me, philosophically, that everybody (myself included) seems to fall into the trap of thinking that a database has to be table-structured. I came originally from a network db background, well before RDB sank its fangs into the field and made every db look like a glorified spreadsheet. If we had simple persistence on a tree structure (ie: environment,) then we have a lot of what a database gives. If we added a per-node colouring (per-node data storage, like arrays in tcl - if we don't already have it, I'm too lazy to look right now) and if we could do things like efficiently traverse a node's children, and a branch, looking for matches by node content, we could treat each node as a record, do very complex searches, and have an interesting distributed multi-access database in gk's native format. Next Q: what if environments were generalised to graphs? Would that work, conceptually? It'd be handy for modelling the comms networks over which the gk runs, for one :) I'm sorry to raise more Qs than I answer, but they're mainly thinking-about questions. > Network issues have always been a problem when it comes to p2p systems. > However, in my research I have come across the various solutions > implemented by the likes of Gnutella and there are some elegant ones > and some ugly ones. I would like addressing to be done by IP > address/port number and not have to rely on host names. Also a > push/pull protocol implemented in the registrar could get around a great > deal of firewall issues. > A repeater type registrar that sits on the firewall would only be a > solution for a few as many IT depts. would simply refuse to run such a > thing. I strongly feel we need to look elsewhere for a solution to the > massive problem surrounding firewalls. > > > All the best, > > Chad Thatcher -- Colin McCormack <co...@ch...> |
|
From: TongMei <ch...@zu...> - 2003-04-09 09:36:43
|
Hi all, Sorry I have been underground for the last month. Had a lot on and have been totally occupied reading through two p2p books and a few other books related to open source, databases, distribution etc. Answering some of the questions raised by Colin McCormack: Both encryption and compression will eventually become important concepts to Groupkit, both for very different reasons and I hope that together we can implement these simple but powerful layers. The point raised about the native implementation of sockets (as opposed to using comm) may also have sway here and I have looked at the source code for simple compression - from the tcl zlib implementation. The packages Trf and Tls would provide a very strong solution for encryption but we would then be dependant on those packages. None-the-less I am still in the process of looking at a great deal of other things and have yet to come to terms with the socket code in gk. Metakit databases and persistence are the things I am currently looking into and would be glad of any help and ideas. I had implemented a shody environment with Mk connectivity but I was not happy with the model and could already see terrible issues arrising with regards to uniqueness, freshness and collision. So I stopped and decided to read the material mentioned above. I now have a clearer idea of how this may be implemented but it really does all boil down to one thing: What is our motivation for db connectivity in Gk? Is it that we just want the ability to load data from previous sessions for persistence, or do we want full blown database support in this environment. The answer to that question will have significant impact on how we proceed. Network issues have always been a problem when it comes to p2p systems. However, in my research I have come across the various solutions implemented by the likes of Gnutella and there are some elegant ones and some ugly ones. I would like addressing to be done by IP address/port number and not have to rely on host names. Also a push/pull protocol implemented in the registrar could get around a great deal of firewall issues. A repeater type registrar that sits on the firewall would only be a solution for a few as many IT depts. would simply refuse to run such a thing. I strongly feel we need to look elsewhere for a solution to the massive problem surrounding firewalls. All the best, Chad Thatcher |
|
From: Colin M. <co...@ch...> - 2003-03-24 02:05:44
|
On Sun, 2003-03-23 at 03:06, Mark Roseman wrote: > Hey Colin, > > Thanks for poking around at GroupKit. > > > 1) rpc - it's doing what comm does, is there a compelling reason for > > using rpc over comm, or comm over rpc? Might be nice to expose the > > underlying socket, to the extent that it'd then be possible to push > > handlers over the top (get compression, encryption, etc.) > > Yeah, they're more or less the same... both evolved around the same > time. > We felt no reason to switch off what we had since it worked, and > minimized > dependencies on other things. Yeah, no reason. Comm's pretty strangely implemented, and since interprocess comms is such a critical facility, it makes sense to have it C-coded for speed. > It'd be nice to add things like > encryption over this, I know its something Chad has talked about. If the socket was exposed, and one could get and set it, then one could use the new(ish) stackable file handlers to push (say) TLS over the groupkit sockets without much work, and with no code duplication. I guess it'd possibly require updating rpc (haven't looked.) > > 2) environment - distributed tree. Very cool. Can one insert procs > > into an environment, as elements? This would be nice because then one > > could map other data structures under it (e.g. arrays.) > > What do you mean by 'insert procs' into it? Now that I think about it, the event facility possibly already covers this - I was thinking about the ability to provide a per-node get/set method, so that one could have an abstract tree with nodes whose contents were implemented by some other storage mechanism (e.g. metakit, arrays, vfs, etc.) While I'm thinking about it: I've written a namespace before, and I had to do extra work to stop internal nodes from being able to contain data as well children. I note that groupkit environments have this quality. Is there some reason this distinction is maintained? I'm just asking to save myself wading through code, to save myself some time, if the answer's not on the tip of your tongue, it's no biggie. > I guess trivially an environment can be used as an array, just never > store anything more than one level deep. ;-) Yeah, an environment could be used to store and therefore distribute an array. > > 3) distribution - I have no idea how you're doing peer distibution. > > In the default architecture, everyone maintains connections to everyone > else, so distributing things around is as straightforward as getting > someone > to send you a copy of something. > > 4) firewalls - each node in a group needs a public IP address - perhaps > > there needs to be some kind of proxy server? > > With the way things are set up by default, everyone makes connections > to everyone else, so its completely unworkable going against any > firewall. > We kept things so that the programming model doesn't depend heavily > on the underlying network architecture though, and the system actually > has a meta-architecture that makes it possible to muck around with that > kind of thing. One thing I'll be playing with is making it easier to > bring out > a completely centralized architecture, which would help addressing > some firewall issues (but that step would give only the most minimal > firewall penetration of course). And/Or one could write a repeater-registrar which sat on the firewall and distributed events by proxy. The architecture will support that, yes. I was mainly wondering if it was TODO or DONE-and-I-couldn't-locate-it. > > 5) obj - might be nice to map to arrays - this would make the thing > > completely transparent. > > Should be possible to do on top of what's already there. Yes, would be straight-forward. > BTW, there's a semi-public Wiki available that we're using for GK > related > development notes, etc. at http://groupkit.roseman.org > Mark Something I might do for my own understanding: document the protocol. If I manage it, I'll send copy. -- Colin McCormack <co...@ch...> |
|
From: Mark R. <ma...@ma...> - 2003-03-22 16:04:56
|
Hey Colin, Thanks for poking around at GroupKit. > 1) rpc - it's doing what comm does, is there a compelling reason for > using rpc over comm, or comm over rpc? Might be nice to expose the > underlying socket, to the extent that it'd then be possible to push > handlers over the top (get compression, encryption, etc.) Yeah, they're more or less the same... both evolved around the same time. We felt no reason to switch off what we had since it worked, and minimized dependencies on other things. It'd be nice to add things like encryption over this, I know its something Chad has talked about. > 2) environment - distributed tree. Very cool. Can one insert procs > into an environment, as elements? This would be nice because then one > could map other data structures under it (e.g. arrays.) What do you mean by 'insert procs' into it? I guess trivially an environment can be used as an array, just never store anything more than one level deep. ;-) > 3) distribution - I have no idea how you're doing peer distibution. In the default architecture, everyone maintains connections to everyone else, so distributing things around is as straightforward as getting someone to send you a copy of something. > 4) firewalls - each node in a group needs a public IP address - perhaps > there needs to be some kind of proxy server? With the way things are set up by default, everyone makes connections to everyone else, so its completely unworkable going against any firewall. We kept things so that the programming model doesn't depend heavily on the underlying network architecture though, and the system actually has a meta-architecture that makes it possible to muck around with that kind of thing. One thing I'll be playing with is making it easier to bring out a completely centralized architecture, which would help addressing some firewall issues (but that step would give only the most minimal firewall penetration of course). > 5) obj - might be nice to map to arrays - this would make the thing > completely transparent. Should be possible to do on top of what's already there. BTW, there's a semi-public Wiki available that we're using for GK related development notes, etc. at http://groupkit.roseman.org Mark |
|
From: Colin M. <co...@fi...> - 2003-03-21 11:38:31
|
Hi, I've been playing with groupkit 5.2 and tcl8.5 - I have a couple of questions/comments of a general nature. I like what I see, btw. 1) rpc - it's doing what comm does, is there a compelling reason for using rpc over comm, or comm over rpc? Might be nice to expose the underlying socket, to the extent that it'd then be possible to push handlers over the top (get compression, encryption, etc.) 2) environment - distributed tree. Very cool. Can one insert procs into an environment, as elements? This would be nice because then one could map other data structures under it (e.g. arrays.) 3) distribution - I have no idea how you're doing peer distibution. 4) firewalls - each node in a group needs a public IP address - perhaps there needs to be some kind of proxy server? 5) obj - might be nice to map to arrays - this would make the thing completely transparent. All in all, very cool. I'll bang this stuff onto the Wiki, too. BTW: I've got a debian packaging thing going. Colin. |
|
From: Mark R. <ma...@ma...> - 2003-03-14 14:39:54
|
I posted the 5.2 release on SF, and updated www.groupkit.org. I'll zap some announcements out later today and see if we can find some people who'd be interested in banging on it again. Mark |
|
From: Chad T. <ch...@zu...> - 2003-02-13 00:11:50
|
New very flimsy make and config files have been added to the /win subdir in CVS so you can build in windows now using the minimalist gcc compiler Mingw32 and msys (http://www.mingw.org/ and http://www.mingw.org/msys.shtml respectively). Chad. |
|
From: Mark R. <ma...@ma...> - 2003-01-30 18:14:00
|
testing |
