RE: [Cxtable-devel] RE:Cygwin...etc..[continued]
Status: Alpha
Brought to you by:
xiarcel
Menu
▾
▴
RE: [Cxtable-devel] RE:Cygwin...etc..[continued]
|
From: Williams, D. <DAV...@ca...> - 2001-12-19 22:55:04
|
Incidentally..I have already begun (in my spare time at lunch here at work) retrofitting the xChessGamex to be xTournoChess.... I think I can have the plugin ready to be "plugged" (that is, functioning, and simply needing an interface to implement and a little tweaking) with a day or two's worth of work... After a morning of hammering out manufacturer SKUs for software, something like the 4-player chess thing is therapeutic...and hunting down bugs among printouts from the night before's test sometimes simply cannot even be approached during the hour I have... RE: The multi-user plugin, though... Do you think that having a separate IP/Port for a "plugin-server" is good? Or do you think that piggybacking off of the existing p2p connection is better... I really do favor #2...but I am wondering what you think.. ~Dave PS-How do I crack the firewall issue? It is important...but I, for the life of me, cannot figure it out... Although... as long as EVERYONE wasn't behind the firewall, it would work.. And if there were five people with one behind the firewall, it wouldn't be major... that's because the "peer-enable" thing... I think windows defaults to port 1080 for proxy.... Or something like that (AOL-IM uses it).. Maybe I should try it out with someone who has a firewall that they can configure.. ~Dave David Scott Williams Computer Associates Marketing Representative-Sales Call Center One Computer Associates Plaza Islandia, New York 11749 tel: +1 800-243-9462 ext. 73431 tel: +1 631-342-3431 (Direct) fax: +1 631-342-5734 wi...@ca... -----Original Message----- From: Borne Goodman-Mace [mailto:bm...@eg...] Sent: Wednesday, December 19, 2001 5:30 PM To: Williams, David Subject: RE: [Cxtable-devel] RE:Cygwin...etc..[continued] I do think this list is the one I would use, yes. I think it would be enough to retro-fit one of the existing plug-ins with the new api to determine how flexible / usable it is, rather than starting on a new plug-in from scratch (though as the list shows, it would be the next logical thing to do anyway, so perfect!). On Wed, 2001-12-19 at 17:20, Williams, David wrote: > SO...if I were to summarize... > > 1- Identify any architectural holes, and fix them. > 1a- Identify any chief architectural changes, do them. > 2- Fix the firewall/proxy issue (??how??) > 3- Swing-i-tate the GUI > 4- Create Plugin API > 5- Write the super-duper-chess-computer plugin > > Would the above be your list of priorities if you were me? > > (Incidentally...I don't actually see how I _could_ make a strong Plugin API w/o making a plugin that ran with it, to ensure that it worked and was not to laborious to use...) > > > > > David Scott Williams > Computer Associates > Marketing Representative-Sales Call Center > One Computer Associates Plaza > Islandia, New York 11749 > tel: +1 800-243-9462 ext. 73431 > tel: +1 631-342-3431 (Direct) > fax: +1 631-342-5734 > wi...@ca... > > > > > > > -----Original Message----- > From: Borne Goodman-Mace [mailto:bm...@eg...] > Sent: Wednesday, December 19, 2001 4:58 PM > To: cxt...@li... > Subject: RE: [Cxtable-devel] RE:Cygwin...etc..[continued] > > > I seem to be having some odd problems with your email not wrapping > correctly in my responses, but I will do my best to respond to all of > your questions / comments, and tell me if I miss anything. > > It is indeed difficult, when dealing with a project that doesn't have > any customers to drive functionality, to determine what to add next, and > I have this same problem with my OMInit project. The process I usually > use is to determine what functionality I think would do the most to > bring people to the product, and implement that first. Once there is a > large user base, then you have people asking you to make changes, and > unless there is a re-factoring or other internal thing which take > priority, you can just go down the user list of wants. > > >From that perspective I think that a nice UI revamp would be of the > highest priority. The most important part of any program to any user is > the UI, because that is all they understand of it. If the UI doesn't > look good, or doesn't react well, they won't use it. > > Before you run off and start on the new UI, I also want to mention that > any structure built on an unstable foundation is prone to fall faster > when stress is placed on it. If there are any lingering communication / > architecture issues, I would suggest fixing these before anyone uses the > code. Once the core is stable, start adding things onto it, and if > designed well, it shouldn't be difficult. > > Most of the people I know (including myself) work from behind a firewall > at home and / or at work. The ability to run the program in this > environment is VERY important. > > I would then suggest the file sharing capability, as p2p file sharing > which works well is always a great way to grab a lot of users. > > The XML / DTD change would be trivial, I believe, if done in the same > way I do it for OMinit, but older versions of the code would no longer > work with the new code, unless we just deprecate the old mechanisms, but > since the user base is so small, this wouldn't hurt at all right now. > Because of this, the change should probably be done before a large user > base is established. > > It is also very important, before a lot of people are using it, to > finalize the Plug-In support, and development of plug-ins is not > necessary for this. As more and more users user the product, 3rd party > developers will use the plug-in support to make their own, if the API is > a nice one. The Plug-In API is VERY important, and I can equate it with > the gaming environment on Windows. The reason for a high percentage of > Windows systems is because that is the only environment you can play > most games in, and because most users run in that environment, game > developers write code for it. This is a cycle, and one you want to > build for the product. Write a great API for plug-ins and get a decent > user base, and developers will write programs for it, and if they are > good, users will user your program only because that plug-in is > available. This is cyclical and the beginning of it requires only > plug-in support, and a decent user base. I feel in this paragraph I at > least matched your rambling and have shown that I can do it myself :). > > Due to the above statement, I think the need for additional plug-ins to > be written should be on the bottom of the list of things to do, even > though they sound like cool ones, and with the above finished, can be > accomplished next. > > I am not easily scared, either by the size of a project, of the lack of > size of a project, as each idea, with work, will naturally become of a > proper size in respect to it's worth (given enough time). > > I have found myself recently (when not at work) preoccupied with my own > OMInit project, and because of some of the abilities it has, and some of > the new JDK 1.4 APIs I want to play with, I have been forced to work on > that more rather than on this. I find the 2 spaces very interesting, > that of a server that can handle a huge amount of traffic for a single > reason, and large number of peers which can also handle a huge amount of > traffic, but in a different way and for multiple purposes. > > I should, sooner rather than later, look more closely at the current > cxtable architecture to validate that it is a solid foundation to more > forward upon, try to pinpoint some of it's weaker spots, and perhaps > even strengthen / replace them myself. I have a few more changes to > make to OMInit before the initial chatting capabilities are code > complete and I shall halt, for a time, on that project, so that I can > look more at this one. > > Most of my work in the past has been in the same space as the OMInit > project, and that is handling lots of client's access to a set of > limited resources. I like cxtable mostly because it is a similar > problem, and just a different approach at a solution. I have rather > grandiose dreams myself, and would like to find that perfect medium > between peer to peer computing and client / server computing and need a > p2p environment to work in to advance that dream. > > You are very welcome, and thank you, > > --bjgm > > On Wed, 2001-12-19 at 15:34, Williams, David wrote: > > Woops..hit "Send" too early on that one... > > > > I am at an interesting state in this development... I have a bunch of little and big unfinished cxtable projects... And I can't decide which to do.. > > > > Naturally...the CVSing of the code has to be complete...and the associated packaging issues... But after that, I am not sure where I had wanted to go...(FIRST, most important outstanding cxtable project) > > > > The only "plugins" that I currently have thought of are game related... and that is not the only exclusive capability of such a network.... However... I am needing to come to grips with non-global multi-"user" plugins..(A SECOND, importance arguable either way, outstanding cxtable project). > > > > That is, a plugin that does not exist for every person from the get-go (non-global) yet would involve more than a simple peer-to-peer (such as Chess). > > > > As far as that is concerned, two plugins come to mind. A Poker game, and a new game called xTournoChess, which is a 16 X 16 board with 4 Chess players instead of two, one on each side of the board... > > > > The idea, then, is implementing the plugin so that either one of two things happens.. -1- There is a plugin-server process running on a machine that mediates between the various clients involved, and runs the plugin.. Thereby requiring a new connection to that server-process from each of the peers involved....OR -2- The initiator of the plugin runs the plugin-manager piece, and all of the communication occurs through the initial p2p connections.... > > > > Does the above make sense? I first thought of -1-, but gravitate heavily now toward -2-... Because, given a set of people (called A,B,C,D,E)... There are two connections between each, and these are readily able to accept messages... tagging the message as "<PLUG><plugname-manager>" instead of "<PLUG><plugname>" would allow the manager piece access to the instructions, which it could then propogate to the involved parties... > > > > This would allow the plugin "logic" to be executed once, and the appropriate moves/instructions to be propogated to the 'screens' or other implementation of the plugin elsewhere... > > > > > > That is one among many of the cxtable projects outstanding... yes...it is game-related as far as implementation, but it would allow the infrastructure to be built for multiple-peer plugins that would extend beyond the "tournochess"... > > > > Other cxtable projects (a THIRD, and equally arguable either way as far as importance is concerned, outstanding cxtable project) are the potential DTD-ing of the messaging, so that a robust parser can be used to process the XML that is passing between the peers/etc... This is also a potentially important project...although cosmetically from the outside it would not reflect much difference (ideally ;-) ) it would greatly impact certain scalability issues in the future... > > > > Another piece (a FOURTH) is a file-sharing (plugin?) piece... This could be run as a "download-server" on each peer, at a dynamically assigned port... The ftp-client could be configured to read to that port, create a data sock, and download... I have a piece of software (currently being used by the Registry Server to publish itself) called Linlyn that I already modified as xDownloadLinlyn, with an interface xDownloadListener... Multi-file downloads would create an instance of xDownloadLinlyn, which would call the xDownloadListener's method to notify it (filename,contents)... Either way...the concept of file-sharing to be plugged in is another work... > > > > Yet another (FIFTH, and potentially of second importance only to CVS, depending on who you are) is the Swing conversion. 'nuff said. > > > > Still another (SIXTH, and also potentally of second importance only to CVS, depending on who you are) is the refining of the GUI (swing or not) and the user processes so that they are more friendly, and more automated... > > > > Still yet another (SEVENTH, and also potentially of equal importance to CVS, swing and GUI-refine) is the setting up for behind configurable proxies/firewalls. > > > > > > I hope I neither scare you off from the huge set of projects I embark upon, nor scare you off from the still potentially limited list I myself can come up with... > > > > When I advertised for help, I didn't know what to expect... I had dreams for this project...and some of them have come to fruition...and I have learned a great deal as a result of simply working on the project... You seem to wish for your role to be that of mentor, and that is perfectly acceptable to me.... ANY level of involvement is great... Code, help organize, dream, spark new ideas...whatever... The reason (mentioned in the help-wanted ad but re-iterated here for clarity) I wanted another developer is more for vision and less for individual lines of code... You certainly have exceeded all of my expectations as far as a team member is concerned... > > > > One thing I might or might not have already demonstrated is my ability to ramble... > > > > If I hadn't prior to this email, I'm sure I did with this verbose email.. > > > > Maybe I could ask you a semi-frank question... What is that you saw in the project that made you want to work on it..? ((There are no bad answers ;-)) > > > > Do you have any thoughts on the above projects? Do you have any more to add that you think might be of more importance.. (All opinions weigh heavily here) > > > > Thanks, > > Dave > > > > David Scott Williams > > Computer Associates > > Marketing Representative-Sales Call Center > > One Computer Associates Plaza > > Islandia, New York 11749 > > tel: +1 800-243-9462 ext. 73431 > > tel: +1 631-342-3431 (Direct) > > fax: +1 631-342-5734 > > wi...@ca... > > > > > > _______________________________________________ > > Cxtable-devel mailing list > > Cxt...@li... > > https://lists.sourceforge.net/lists/listinfo/cxtable-devel > > > > > > _______________________________________________ > Cxtable-devel mailing list > Cxt...@li... > https://lists.sourceforge.net/lists/listinfo/cxtable-devel |
