Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
OS X Businesses Operating Systems Apple

Hydra: Rendezvous-Enabled Text Editing 392

Tokerat writes "It's incredible what some people dream up. A recent post on MacSlash brought this little gem to my attention, and I have a feeling some of you fellow /.ers will be screaming to get your hands on this: Hydra is a Rendezvous-enabled text editor, which allows several people to edit a text document at the same time. Imagine doing some extreme programming with this, with one person writing code and another following the first and correcting their mistakes & making optimizations simultaneously? It already works with Apple's Project Builder, supports syntax coloring, and the ability to manage access on a per-document basis. Future improvements will include support for RTF and much tighter integration with Project Builder. It looks to me like these guys are really on to something here."
This discussion has been archived. No new comments can be posted.

Hydra: Rendezvous-Enabled Text Editing

Comments Filter:
  • by Khazunga ( 176423 ) on Friday April 04, 2003 @01:05PM (#5661763)
    Bah! Emacs and Xemacs have been able to do this for at least the last half-decade. It works over the X network protocol. It's not buzzword compliant, like Rendezvous, but it's very very effective.

    For the sake of completeness, in Xemacs, the command is:
    M-x make-frame-on-display

    • by dunham ( 35989 )
      I've done this too with XEmacs. Two authors working on a paper at the same time. The only issue is that you have to avoid commands that cause a prompt in the minibuffer (it will show up on both displays).

    • by krisp ( 59093 ) on Friday April 04, 2003 @01:12PM (#5661831) Homepage
      Rendezvous, however, is unicasted, therefor noone on the lan needs to know anything about ips or networking in order to get it to work. That's really the only thing thats neet about it, the fact that two people turn on the program, and have it automagicly find the other programs running on the lan.
      • by Lathi- ( 156581 )
        Rendezvous, however, is unicasted, therefor noone on
        the lan needs to know anything about ips or networking in order to get
        it to work.


        Of course, this also means the two programmers have to be on the same
        LAN segment. Rendezvous doesn't route.
        • by gozar ( 39392 ) on Friday April 04, 2003 @01:23PM (#5661938) Homepage
          You can also join via an IP address, for those times that you are not on the same subnet.
        • by .@. ( 21735 ) on Friday April 04, 2003 @02:56PM (#5662841) Homepage
          Of course, this also means the two programmers have to be on the same LAN segment. Rendezvous doesn't route.
          However, it is possible to build a Rendezvous proxy. Given that, it should be fairly easy to set one up to listen for Rendezvous apps on one network, and proxy-advertise them to another. This would be easy to do with the mDNSClientPosix and mDNSProxyResponderPosix example code available from Apple [apple.com].
        • Of course, this also means the two programmers have to be on the same LAN segment. Rendezvous doesn't route.

          Actually there's a "connect via Internet" option where you can connect to anyone with an IP address and the right port open. I was very skeptical at first, but it works beautifully. We've been testing it out all morning. Unfortunately, I'm seeing what appears to be a filesize limit... I tried to open up a 1000+ line file, and I didn't get the entire file open... very strange, and sad... I hop
      • krisp,

        Rendezvous is a standards-based implementation of multicast DNS. It uses multicast transport of those packets to cover a campus network. Unicast would refer to a single IP address source and destination.

        Just wanted to correct you.

        Pat

        • by b0r1s ( 170449 ) on Friday April 04, 2003 @01:30PM (#5662004) Homepage
          Rendezvous is a standards-based implementation of multicast DNS. It uses multicast transport of those packets to cover a campus network. Unicast would refer to a single IP address source and destination.

          You're right and you're wrong.

          The application uses multicast DNS to FIND the service, but then reverts to unicast for actual USE of the service. It'd be quite silly to send all of that information all over the network.
          • by jmilne ( 121521 ) on Friday April 04, 2003 @01:47PM (#5662179)

            The application uses multicast DNS to FIND the service, but then reverts to unicast for actual USE of the service. It'd be quite silly to send all of that information all over the network.

            I think you're confusing multicast with broadcast (Which, admittedly, a number of dumb switches tends to do as well. And of course, a hubbed network treats them the same as well). Multicast traffic only goes to those hosts that have actually joined the multicast group. In this particular case, that'd be anyone who's collaborating on a given editing process. Multicast would be a rather good way to go for this sort of project. In fact, a couple of multicast tools (wb for "whiteboard", nt for text editing) were created for just that purpose. And the great thing about doing something that way is that you could be working on a file in California, I could be working on it in Virginia, and twenty other people could be working on it elsewhere, and I'm only sending out a single copy of my packets, and only to the twenty-one people who actually are working on it as well.

            If they're not using multicast for Hydra, it's a shame, because multicast would really be a great way to perform this type of operation.

            • Rendezvous uses link-local multicast, not broadcast.
              "Multicast DNS Responder (mDNSResponder), the component that listens for and responds to DNS-format query packets, sent via IP Multicast to UDP port 5353" From: http://developer.apple.com/darwin/projects/rendez v ous/

              I don't see why Rendezvous could not be enabled to use global multicast. Apple could use a GLOP address (http://www.faqs.org/rfcs/rfc2770.html) for each application that wants to have a global presence.

              Anyway, Rendezvous != Broadcast.
              Link-Lo
    • by Tom7 ( 102298 ) on Friday April 04, 2003 @01:18PM (#5661891) Homepage Journal
      Yes, indeed. Unfortunately, emacs shares the minibuffer between each frame, so if one user tries to start a search-and-replace, for instance, everything goes to hell. Even in this crippled state, though, I found this pretty useful. (I'm willing to bet that Hydra doesn't have the fancy features that Emacs has, anyway, so maybe they're on equal ground after all!)
    • by Anonymous Coward
      emacs/xemacs have been able to do it, but that's like saying "it's possible to shove your leg down someone's throat."

      It may be true, but it's not something you want to do normally.
    • by eyeball ( 17206 ) on Friday April 04, 2003 @01:41PM (#5662113) Journal
      Ok, so you pop an Xemacs frame up on my x server. What prevents me from doing 'esc-! cat ~/.ssh/*', or something more nefarious?

      I wish I had a nickle every time someone said "emacs can do that."

  • That's just plain sick! (In a good way).

    Nearly as cool as the hack to have iTunes stop playing when you walk away (Bluetooth).

    -psy
  • Nifty! (Score:5, Interesting)

    by .@. ( 21735 ) on Friday April 04, 2003 @01:11PM (#5661826) Homepage
    That's very cool. Rendezvous is really coming into its own. I wrote up instructions on how to Rendezvous-enable pretty much anything you'd like [bitshift.org], using any Unix box and a bit of C code and shell scripting.
    • Excellent, I hope you don't mind if I linked to it from the small developer meta-index on zeroconf/mdns site dotlocal [dotlocal.org].

      This is all very old technology, but it's done in such a way that it's transparent, and that transparency in modern chaotic networks is more useful than ever, I for one am a fan of Rendezvous and even did a small ground-up implementation myself (mdnsd [dotlocal.org]).
    • those are good instructions, but I had to copy the text out of your webpage an into a text editor because otherwise it was all in one narrow column.
      I don-
      t like
      having
      to sc-
      roll
      all t-
      he ti-
      me.

      other than the crappy web design, (seriously, wtf is with designing so in ONLY looks good at 640x480?) those were nice directions, I may have to start fiddling with that.
      • Re:Nifty! (Score:3, Informative)

        by .@. ( 21735 )
        1) Reduce your font size

        2) I use a TiBook most of the time, and I don't need a page that big

        3) Even when I'm working on my desktop (2048x1536), I don't run huge browser windows

        4) Many browsers interpret stylesheets and tables slightly differently, and getting that layout to look correct in all of them is nigh impossible

        5) Fixed it, so you can stop complaining.
  • Wiki (Score:3, Informative)

    by arvindn ( 542080 ) on Friday April 04, 2003 @01:14PM (#5661852) Homepage Journal
    Although it is not used for programming, the wiki is an excellent method of collaborative editing. Take a look at the wikipedia [wikipedia.org]. There are lots of other wikis around on the web. The great thing is that you don't need any special software, just a browser.
    • I don't think you get it - two people can't edit the same file at the same time on wikipedia - they have to take turns. This is literally two people in the same file at the same time, updates between them in real time.
  • by veldmon ( 595009 ) on Friday April 04, 2003 @01:15PM (#5661863)
    this is what an operating system is supposed to enable. That is why I recently made the 'switch' to a PowerBook running OS X Jaguar.

    Rendevous is a 'framework' that enables an amazing array of functionality in many different applications. For instance, in iChat I can use rendevous to converse with others on my local network, devoid of going through a central authority (server) on the internet.

    Rendevous is also open source. I think it has to be said that Apple is making great strides with open source for a commercial company with roots in strictly proprietary technology.

  • Yay! (Score:4, Funny)

    by guido1 ( 108876 ) on Friday April 04, 2003 @01:15PM (#5661868)
    Now everyone can know the fun of multiple personality disorder!

    Shut up jerk! ^H^H^H^H^H^H^H^H^H^H^H^H^H

    No, it's really a good ^H^H^H^H crappy idea!

    Quit doing that! Ack!
  • Typo (Score:5, Funny)

    by Repugnant_Shit ( 263651 ) on Friday April 04, 2003 @01:16PM (#5661875)
    Future improvements will include support for RTF

    Someone left off the "M" at the end.
  • by matiasp ( 170413 ) <matiasp.email@com> on Friday April 04, 2003 @01:16PM (#5661876)
    I am skeptical about doing pair programming remotely... From my (limited) experience you need to be physically next to the other person, and in fact the whole point is that there is one keyboard that you take turns on, not simultaneous typing.

    In fact Kent Beck (inventor of XP) was at my school recently, and I asked him what he thought about this kind of "remote pair programming" stuff. His answer (paraphrased): "Forget it. You need to be able to smell the other person's farts".

    • What if you are close enough to smell the other person's farts, but you have two computers? Then if the other guy wants to futz with something, he can do it without having to screw around.

      Of course, I've never done any XP, so I don't really know....
    • You need to be able to smell the other person's farts

      Now there's an argument which will have people lining up to try XP.... Sometimes people should just think about what they're about to say before saying it.

    • by Zoop ( 59907 ) on Friday April 04, 2003 @01:31PM (#5662015)
      You need to be able to smell the other person's farts

      That is the most convincing argument against XP I've yet heard.
    • How'd he invent it?

      Seems to me he RECOGNIZED that XP existed, and perhaps documented it ... but the techniques have been around for quite some time.
    • "Forget it. You need to be able to smell the other person's farts".

      Finally, a long-sought-after incentive to get more of our youth interested in computer science.

      I can see my high school students knocking down my door to sign up for the chance to smell each others' flatulence.

      Thanks, Mr. Beck.

    • by SuperBanana ( 662181 ) on Friday April 04, 2003 @02:25PM (#5662526)
      I am skeptical about doing pair programming remotely... From my (limited) experience you need to be physically next to the other person, and in fact the whole point is that there is one keyboard that you take turns on, not simultaneous typing.

      Think of it more like...'live' CVS. Think of it also not in terms of just programming, but other text editing- like, say, a book. According to the Jabber guys, this sort of stuff is incredibly handy for legal documents, which are heavily co-authored.

      If you've got six guys in a meeting room, six laptops, and one doc, you can quickly say "okay, bob, edit section 6. Jane, section 3" etc..nobody needs to worry about re-syncing copies of the doc, or CVS servers, or any of that...and people can even watch as the guy edits his particular section. Maybe they notice something amiss, and mention it- "okay, can you rewrite that phrase?" While Bob continues writing, Jane corrects the one phrase...etc. Each team member can work with any number of other people(including zero, ie, on their own.)

      While it's fun to joke about people trading insults and deleteing other's writing, that's moot- if you don't have good team dynamics and people are hostile/uncooperative/ego-tripping, that's a people problem, not a technology problem. You can't solve people problems with technology. Well, you can, but it's often far more time-consuming. What takes a sysadmin an hour or two(configure proxy to block porno sites) can often be solved by a 1 minute phone call to HR("Bob is swamping the line browsing porno" HR to Bob: "Surf porn sites again, and you're fired.")

  • I thought they meant this one [tibco.com] which we use a lot. Now a text editor which talks over the tib would be truly cool, as it would be multiplatform, not just Mac.

    Oh well, maybe I should write one :)
  • Why don't we have this in my office? Being locked out of text doccuments that I share with a half dozen other network users for the better part of a day has cost me a lot of productivity..
    dreaming of a mac-equipped office.....
  • Unix tools (Score:2, Informative)

    by benja ( 623818 )
    I've done this-- with emacs and screen. You set up a shared account on a computer and run screen on it; two or more people attach to the same screen (that's 'screen -x' for the second and following people). We had two screens running, one for editing and one for compiling. In addition to that, we've communicated through an IRC window.

    It works. One of the surprising results was that you don't actually need to 'pass the keyboard' explicitly: you wait for the other person to stop typing, a bit like you wait

  • by agent oranje ( 169160 ) on Friday April 04, 2003 @01:18PM (#5661899) Journal
    I just downloaded Hydra and fired it up... and I'm really, really, really impressed. The program itself is very fast and clean, with an intuitive interface. Yes, other programs are capable of multiple users editing a single file, but I don't know of any programs that allow for this with a single mouse click.

    We'll see how useful this actually is in time, but it is a neat little program.
  • Could someone tell me how rendezvous is important to this process? I don't understand. In this context, aren't the same things doable just as easily with standard network sockets?
    • by MyNameIsFred ( 543994 ) on Friday April 04, 2003 @01:35PM (#5662056)
      Rendezvous is not essential to this process. What it does is make the process easier. For example, over standard TCP/IP processes you would need to know the other person's IP addres before making the connection. Rendezvous eliminates this step, slightly simplifiying the process.

      To use an analogy, just about everything done via USB can be done via legacy ports. However, USB makes it easier. That's what rendezvous brings to this process.

      • by Jimithing DMB ( 29796 ) <dfe@tg[ ].org ['wbd' in gap]> on Friday April 04, 2003 @05:20PM (#5664241) Homepage

        Having just studied the Cocoa text system I'd be willing to bet they simply hooked up another field editor class to project builder's text system.

        Cocoa's text system is, shall we say, different when compared with other toolkits. It exposes this amazing API that lays the fondation for text editors, word processors, desktop publishing, web browsers (Berners-Lee used cocoa's predecessors), and anything else which does any kind of text management or layout.

        The only drawback I can see to it is that a programmer who expects to do one-off writing of text to a drawing surface is really in for a surprise. However, I'm in the process of porting wxWindows to run atop of Cocoa and have found that even one-off text drawing hardly takes much effort once you realize how the classes (NSTextStorage, NSLayoutManager, and NSTextContainer) interact with each other.

    • Re:rendezvous? (Score:3, Informative)

      Rendezvous basically allows all "nearby" copies of Hydra to find each other without any intervention from the users. So, it saves a config step and, especially with wireless networking, becomes a very convenient way to set up networks in general.

      If you're really confused about what Rendezvous is, try substituting the words "Universal Plug and Play" or "Zero-conf networking" for Rendezvous and see if it helps...
  • by gozar ( 39392 ) on Friday April 04, 2003 @01:27PM (#5661975) Homepage

    Our php programming class has just started using this. It is going over pretty well, and easily works with the 20 students in the class all working on the same document. The teacher can pose questions to certain people in the group, who can then type the answer directly into the document.

    This is one of those applications that can really show off what OS X can do. It's not only what's possible technology wise, but how simple it is to set up and use. It took all of 10 seconds to use Apple Remote Desktop to copy the Application to 24 machines in the room.

  • what a nightmare (Score:4, Insightful)

    by drxenos ( 573895 ) on Friday April 04, 2003 @01:27PM (#5661978)
    Imagine doing some extreme programming with this, with one person writing code and another following the first and correcting their mistakes & making optimizations simultaneously? Oh, great, not only would the moron be breathing down my neck while I was typing, he'd be changing my code to! What a recipe for disaster, even when ignoring my revulsion to the idiocy that is Extreme Programming. Someone should not be making changes to your code while you are writing it. That's what a peer-review is for: when you have time to study at it in its entirely and understand the whole scope and logic of it. Second-guessing what you "think" he meant in a code fragment is a piece-o-crap wait to be written. And premature optimization has been proven to be very, very bad time and again! *shudder*
    • by JohnDenver ( 246743 ) on Friday April 04, 2003 @04:23PM (#5663533) Homepage
      ...in real time doesn't mean the rest of us are also incapable.

      I personally have never had a problem with pair programming. A lot of the time it's like having a second pair of eyes and two extra brain hemespheres, depending who you are working with...

      Pair-Programming obviously isn't for you.

      I've even found pair programming to be beneficial when sitting with someone who's either learning, or lacks experience as it forces me to explain coherantly what I'm doing and why I'm doing it, which I find helps give me perspective.

      Like I said, Pair-Programming obviously isn't for you.

  • by neurostar ( 578917 ) <neurostarNO@SPAMprivon.com> on Friday April 04, 2003 @01:28PM (#5661985)

    since vi [vim.org] doesn't have it!

    :-P

    • screen does, though. the "small tools" philosophy way of doing things that both vi and screen adhere to says vi is the text editor and screen is the terminal handler. so you can do this kind of collaboration using your editor, your mail client, your web browser... anything that runs from a console. and your editor can stick to adding editing features.
  • by Wuffle ( 651894 ) on Friday April 04, 2003 @01:29PM (#5661993) Homepage
    Geek1: *Types some code*
    Geek2: *Makes a few changes*
    Geek1: 'wtf you doing??!!!'
    Geek2: 'ure code is shiat, my variables pwn'
    Geek1: 'stfu steve!' *deletes other geeks function*
    Geek2: 'ben you bastard that took me 15mins to write!!!'
    Geek3: *types 'PWN j00 BASE!!!!' 15 times*
  • Seriously, not to belittle their achievements, but this smells like a research project.

    Yes I can write a demo in eight weeks as well (their FAQ). The problem I see is not the demo, but making it work in real life.

    I use SlickEdit as an editor because it enables context sensitive popups, object browser, etc, etc. If all of this information were live the computer would come to a crashing halt. Remember if your team increases the network traffic will increase exponentially.

    So until it becomes a real app
    • Reconsider? (Score:4, Insightful)

      by 2nd Post! ( 213333 ) <gundbear.pacbell@net> on Friday April 04, 2003 @01:39PM (#5662099) Homepage
      I think you're missing the point; Hydra would just be the source editor, while, as described, Project Builder would be the IDE into which Hydra plugs in.

      So all parties are communicating and sharing the file, with the purpose built Hydra, while the context sensitive popups, object browser, and other information is handled by Project Builder (IE, your Visual Studio).

      It's like using Notepad to edit the source for a project in Visual Studio or Borland's IDE.

      So any work on Hydra just needs to concentrate on making collaboration better, on making editing and markup easier, and leaving the build, management, and design process up to other more capable tools.
    • Not really. Imagine writing business cases. You won't need a scribe to write down 30 people's business cases. You can have all 30 people (well, 30 IS extreme) doing it themselves.

      In the case of two or more developers colaborating on an issue with code.

      Any place where two people are either remote, or its just a hassle to share a keyboard, this r0x0r. All you need is N amount of computers and a conference call/room.

      -s
  • by Jennifer Ever ( 523473 ) on Friday April 04, 2003 @01:30PM (#5662005) Homepage
    But after reading this:

    Imagine doing some extreme programming with this, with one person writing code and another following the first and correcting their mistakes & making optimizations simultaneously?

    I can't imagine you do either.

  • If you think wars for the remote control are bad...
  • of dubious value... (Score:4, Interesting)

    by lobsterGun ( 415085 ) on Friday April 04, 2003 @01:32PM (#5662022)
    Colaborative programming requires much more than just a text connection. There is a great deal of information conveyed in pacing and tone of voice that just can't be easily communicated through typing.

    I'm thinking that without simultanious audio, such collaboration would be more of a hinderance than a benefit.

    • by Teancom ( 13486 ) <david&gnuconsulting,com> on Friday April 04, 2003 @01:40PM (#5662103) Homepage
      In reply to your concern (as well as various other, like the fart-smelling guy), there's nothing about this that makes it so you *can't* sit next to each other. Case in point, I share an office with another guy, and we quite often lean over and help each other out with stuff (our desks are side-by-side, I could reach out and hit him if I wanted to). We've even done some hours+ pair programming sessions. If we could both have been working on the program at the same time, it would *definetly* have sped things up. Of course, in order to do that, we would both need to get Macs :-)
  • The Jabber [jabber.org] guys were looking to use the Jabber protocol to make a collaborative editor, too...among other things. They're looking to have Jabber, since it's XML based, get used for much more than just text messaging.

    This Rendezvous editor looks great for "a bunch of macheads sitting at a meeting"...but Until Rendezvous is extended to more platforms and actively used, this is useless for most people- I serve as 'editor' of a large manual, and nobody else in the group of about 12 has a Mac(I use Lyx/Latex

    • by Wilersh ( 237791 ) on Friday April 04, 2003 @02:17PM (#5662462)
      Hydra works over the internet also. You don't have to be "sitting at a meeting", but you do need a Mac. Of course nothing stops you from buying a Mac if you want to.

      Not sure what using LaTeX has to do with any of this. Hydra does support LaTeX color syntaxing and will eventually work with typesetting your documents too from what it says in the FAQ. Of course TeXShop already does that nicely on OS X. Getting edits from many users for a shared LaTeX file seems to work great with Hydra. I just had a friend share a paper I wrote on a machine across campus and I was able to find it instantly with Hydra (and Rendevous), add my LaTeX modifications and was done. A quick run of latex at the command line on his end and we were set!

      I may not be understanding why Jabber "may" be so great for this type of work...someday in the future, but seems that Hydra is doing it today, and will only get better in future.

      Cool tools like this that I can setup in seconds and teach ANYONE to use in a minute are why I'll never mess with Linux for desktop work again. My time is money!

      Wilersh
  • Rendezvous (Score:4, Funny)

    by rjamestaylor ( 117847 ) <rjamestaylor@gmail.com> on Friday April 04, 2003 @01:34PM (#5662046) Journal
    If you start editing my code on the fly after I code it you'll earn a Rendezvous with my FIST!

    Sorry, that was my first thought...

  • by klapton ( 457314 ) on Friday April 04, 2003 @01:39PM (#5662095)
    To be truly useful for multi-user editing, wouldn't it be helpful to have some sort of version control built in?
    What kind of undo facility does it have? Does it keep a history journal of which user makes edits so that edits can be rolled back?
    How about a way to lock parts of the document?
    • Exactly, two people editting the same document at the same time is a recipe for disaster. I don't mind collaborating, but you can bet that I want some tools that will allow me to keep a revision history of any editting done. The last thing I would want is some hoser editting out the last 4 hours of my work.

  • SupraSphere (Score:4, Interesting)

    by Anonymous Coward on Friday April 04, 2003 @01:41PM (#5662110)
    We have a project that has somewhat similar ambitions but with Java. Basically, we have integrated threaded messaging, revision control, group document editing, instant messaging, contact management, mailing lists, file management, and workflow into a single interface.

    Currently, it does not have "live" group document editing because of lack of perceived demand. Quite frankly, my programming style is too unstructured for it to make sense for me. However, this is a fairly simple thing to add if enough people want it. We do have asynchronous group document editing.

    The beta installer is available at http://www.suprasphere.com/sbeta. You will need java >1.4 to run it. It will download one update, and you will need to login again. We are working on using the OSGI component architecture so that modular updates can be achieved without needing to "reboot" the whole thing with every update.

    We will do an open source release as soon as we finish the revision control engine. We want to be able to use SupraSphere to accept changes and manage its collaborative development as soon as we hit 1.0. The revision control will work somewhat like CVS, but you can set update "thresholds" for certain files that will require the voting approval and/or rating of certain group members. For example, you can require that an update to a common library must receive the approval of at least 60% of the project members, with an average rating of > 4.0/5.0.

    You can also create builds with different versions of the source files, which will show up inside the interface immediately for others to test. Then, the specific files of those versions can be tagged as a cohesive update set for voting approval.

    One strength with this project is the security. Everything is encrypted and secured with triple DES sockets and zero knowledge authentication. This makes it easy to pull from many different sources into one view. This way, if you're involved with many projects at once, you can query different source databases for only the files and discussions that are pertinent to you.

    We would greatly appreciate your feedback on the beta before we go gold. There's a discussion engine with contextual highlighting (you'll see what I mean when you get in there). If there are some ideas of things you want, please let us know asap, as we're planning 1.0 source release at the end of April.

    Thank you for your consideration.

    David Thomson
    SupraSphere Founder
  • Heheh (Score:5, Funny)

    by fredrikj ( 629833 ) on Friday April 04, 2003 @01:50PM (#5662209) Homepage
    Can you imagine the endless possibilities of fun in this? Just imagine two developers disagreeing about a piece of text, then fighting for minutes, one guy typing frenetically to outperform the other guy's continuous backspacing :)
  • This is just what Computing needs. While this may not be the best way to do programming it does lend itself to brainstorming. As a way to solve problems and such it sounds very nice.

    More strange ideas and crazy apps will by statistics bring out those killer apps that has been absent for a while.
  • I'm trying this with a friend and it looks like there might eventually be a possibility of maybe using this over IPv6. When I connect to his address, it says "Searching for Documents" and finds none. Is anyone experiencing this with other protocols?

    I think the best way to use this is in a single office, where people can talk to eachother and work on the same code without having to share a keyboard/screen in an akward way. Pair programming is great when you can quickly exchange ideas with your pair.

    On a si

  • by cjhuitt ( 466651 ) on Friday April 04, 2003 @02:06PM (#5662358)
    A couple of things not yet mentioned here...

    First of all, for pair-programming or whatnot, I would imagine that this would of course work best with the two programmers sitting next to each other. However, this would allow both programmers to select/enter/point out stuff to the other person without having to shuffle keyboards and mice around, which I think would be very convenient.

    Secondly, the changes that occur to the documents can be color-coded in order to show who has made what changes. I assume this is lost when the document is saved, closed, and reopened, but it does provide good feedback on who has done what to the document. I would imagine that, like pair-programming, this could be a decent learning tool, if you have mistakes that you made pointed out right away in this manner.

    Third, until the syntax coloring can be modified via preferences, this isn't as useful to me as it could be. I like to have the same syntax coloring at work, school, and home in order to make my life a lot easier - and each area has different editors for me to use. Once that can be done, I imagine this could become quite useful to me, at least.
  • i think it goes without saying, okay well maybe it does, is that with the exception of rendezvous, which is cool, this can all be implemented in java. rather easily with sockets and rmi. plus by making the data protected and synchronized, and separating things in separate threads, you can make it rather safe. the only thing i guess java lacks is rendezvous, but since this is on os x, and java is a core component, rendezvous is accessible on pure java.

    i'm not criticizing, and havign used rendezvous only
  • by lars-o-matic ( 533381 ) <lars&middletonia,ca> on Friday April 04, 2003 @03:11PM (#5662956) Homepage
    Many posters have made many negative comments. Fine, be like that. Off the top of my head, plus 10 minutes' research:

    Emacs does all the same stuff and much more
    Okay, granted. It's good to have choice, isn't it? Hydra looks easier to use for many people.

    MS NetMeeting
    ...looks more whiteboard/desktop-oriented than document-oriented. Good feature list; royalty-free is unexpectedly nice.

    At microsoft [microsoft.com] it appears NetMeeting is frozen back at Win98 / NT4, which is less good. I code for web in a Windows shop (Mac at home); I'll look into NetMeeting more.
    Other people will mess up my code
    ...so collaborate only with people you trust. No-one? I guess you don't need collaboration tools.
    Slashdot posts too much piddly Apple news
    I must be more in the editors' target audience than you are: I think Hydra looks very cool.

    It's already cool as a 1.0 product, it's FREE, and it may help inspire a more collaborative workflow. (For some kinds of work, for some people, some of the time.)

    Not into it? Scroll down instead of taking the time to complain. Jeez.
  • by Quixadhal ( 45024 ) on Friday April 04, 2003 @03:49PM (#5663246) Homepage Journal
    ...we used to do the same thing when they had the IBM PCjr demo machines at K-Mart. We'd grab an extra wireless keyboard and stand behind the people using the machine and "correct" their typing, much to their consternation.
  • Mac only? (Score:3, Informative)

    by Tokerat ( 150341 ) on Friday April 04, 2003 @06:42PM (#5665149) Journal

    I've seen alot of negative comments here about Hydra being Mac only. There is talk of making Hydra open source, perhaps you should contact the Hydra team and express intrest in porting Hydra to your favorite OS? If they do make it open source it's surely going to be because of intrest in the project and, as stated on their page, it surely will be a large undertaking due to the fact that it's written entirely in Objective C and Cocca. Unfortunately this means a complete re-write will be needed, but you didn't have anything to do this weekend, did you? ;-)

    Also, if you want to get active about making Rendezvous a reality on more that just the Mac (which is what Apple and Zeroconf are hoping for), Zeroconf.org [zeroconf.org] is a good place to start, and there is a SourceForge project [sourceforge.net] devoted to Zeroconf on Unix and Linux as well.
  • Not just rendezvous (Score:3, Informative)

    by geniusj ( 140174 ) on Friday April 04, 2003 @10:00PM (#5666320) Homepage
    I haven't read *every* comment to see if this was already mentioned. But I saw some people disappointed that it 'only supported rendezvous' .. Please note that this application allows you to just join a session by specifying a host/ip as well, so it's not JUST rendezvous enabled.

    Cheers,
    -JD-
  • by BohemianCoast ( 632363 ) on Monday April 07, 2003 @08:27AM (#5678061) Homepage
    Three of us used Hydra extensively this weekend, preparing editorial material for the next issue of our fanzine, Plokta [plokta.com]. It's certainly much more than a demo, as some have suggested. We found it very straightforward and effective to use, and much simpler than any collaborative editing tool I've previously encountered. We were working in a single room on a wireless LAN. Hydra is a relatively simple text editor, with syntax colouring for a range of languages (as it has HTML, it satisfies my limited requirements in a text editor, too). Document owners can choose to share them (and whether to control user access to shares), and LAN users can see a list of all shared documents and ask to join those they're interested in working on. Once shared, text created by each participant is separately coloured. Participants are handily identified with iChat icons and the position of their cursor is noted. It works as advertised; it's possible to work fully interactively and edit simultaneously, which takes some getting used to. When editing editorial text, we would have found it helpful for deleted text to be indicated with strikethrough rather than just deleted. Otherwise Hydra was extremely handy. It both sped up and simplified the process of writing and re-writing material, and version control risks were eliminated. When material was ready to be imported to the laid out document, it could be cut-and-pasted from Hydra, rather than the usual process of saving a copy to the server and then opening on the machine on which the layout was being done. Only other drawback; those of the team not using Mac OS X were disenfranchised (it's taking advantage of Cocoa), and we just can't afford to buy those PowerBooks fast enough. We've also done a test session over the Internet; sharing documents (through our various firewalls) is slightly more fiddly. Once participants and documents are identified, the program remains as easy and straightforward as on Rendezvous. Our wishlist item; that this collaboration system is fully incorporated in Apple's rumoured forthcoming OS X native word processor. Bottom line; it's very useful indeed, and it's free.

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Working...