The questions are in german, the answers in english. You'll probably
grasp them.
ich weiss nicht, ich hab teilweise das gefühl, dass ihr auf der stelle tretet
are you checking the cvs diff of psyced once a week? you should be able to see that month after month hardly a day passes where no work is being done. a lot of work doesn't sum up into neat features to mention on the next release announcement, sometimes we don't even talk much about details in the chat.
- Lack of transparency - cvs diff isn't exactly a good news medium. Freshmeat is better than nothing, but we now have a News page on this wiki and maybe I will actually dare using mailing lists.
lynX zweifelte ob es überhaupt psycclients geben soll?
no no that's exaggerated. i only said that we will probably not support full fledged native clients for the 1.0 release of psyced (right now i'm even thinking of skipping directly to 1.1 so people stop having one-dot-o expectations!!! ;)) but everything else like applications using psyc between each other or in communication with a server already exist today, just look at perlpsyc for a start.
so ne administration für apache+ftp etc, die zentral gesteuert werden sollte... das hab ich über böses unsauberes php-scripting gemacht, ... hätte man auch schön über psyc lösen können
yes, you could have done it in psyc. no problem really.
i know that's the kind of minimal answer you really love to hear, but we will get into details as we go on with this discussion. ;)
aber ich hätte da keine lust dann verbindung über jabber oder irc machen zu müssen
no no, jabber and irc aren't interfaces supposed to be used that way. you can use neat and cute psyc protocol the way tools like psycmp3 or psycfilemonitor do in perlpsyc.
aber das sind sachen die ich momentan arg notwendig hätte... thema daten über einen psyc channel schicken wo andere lauschen
you can let applications enter rooms via native psyc and remain subscribed until the event is submitted to it. yes, you can absolutely make applications that make use of psyc's multicast rooms (unless it's a fancy end-user client). i must admit we haven't done any distributed application yet apart from the symlynX chat events, which actually count for a lot.
ist mittlerweile eine lösung raus für binärtransport von daten über psyc? weil gabs vor paar monaten noch nich, nur theoretische gedanken
the psyc protocol allows for binary data transfers. perlpsyc implements it. psyced instead has some limitations in that field, but why would you need to transfer binary data through the psyced if you can do it peer-to-peer? or do you specifically need the multicast to send something to multiple recipients? then we either have to fix up psyced, or you have to write a custom channel server and router.
funny, we have the protocol syntax that should allow for binary multicasts, but for cumbersome details we can't use it right now. that's indeed something we should take care of soon, because we don't want to keep anyone from making the truly innovative applications!
still, what you can always do is to use the room for the signaling (exchange events between several peers), then use direct p2p connections for data exchange (be it psyc or maybe just http), or launch external apps like rsync for whatever job to be done.
vor allem kann ich dann einfach sehen wer überhaupt da ist wenn die alle in einem raum sind
which tells me that in the long run rooms should learn to discern types of members so that, as a human, entering a room full of applications, doesn't look just like entering a room full of people, giving this in my eyes unprofessional impression of having to do with "bots" or even "fake users."
- <kol_panic> On asciiking.com, there are two conventions dealing with this. One is that applications are expected to be implemented as part of the room programming when it is practical to do so. The other is that bots are generally named with a leading underscore unless they expect to be able to pass a Turing test. Conversely, humans who choose a name with a leading underscore are not expected to pass a Turing test.
wobei, frage. du meinst p2p implementier ich anhand meines psyc ports... das würde bedeuten nen psyc server auf jeder kiste? wäre ja sinnlos? wobei hm
no not necessarily - stop thinking an application cannot accept connections - native psyc clients are generally expected to have an accessible port one can connect to for direct peer-to-peer interchanges. it doesn't have to be port number 4404 - the UNL is expected to come with a non-standard port number each time - sure you could simply use a psyced on each host to implement your application with, but it wouldn't be using any of its regular psyc server functions. you would use it as a framework for your app, just like you would with perlpsyc. and sure you can make every node in your application also a node in the multicast tree of your chatrooms, but it isn't necessary. it may turn out wise, depending on the needs of your app.
was is btw mit dem perlpsyc? oder wird der nicht mehr gepflegt?
we are lazy doing releases, but never say something's not moving if you haven't checked the cvs diff. el keeps working on psycion whenever he finds the time to, whereas i occasionally add new applications to perlpsyc, like the new syslog event notifier. formally the Net::PSYC implementation is at least as powerful as the net/psyc implementation in psyced. it works well and is stable. it is a good idea to make psyc applications based on Net::PSYC as we will keep it up to date even should we change something fundamental about the protocol (which we are not excluding, since we want the best). so the reason perlpsyc isn't moving forward so fast is mostly because within the expectations it is doing the job. it works. it's there. go enjoy it! ;)
cvs diffs lesen hilft nicht immer, weils nicht immer aussagekräftig sind
sure you can't possibly always understand what's going on when reading a cvs diff, but you asked about the activity of a project, and you could still use a very simplistic activity factor for cvs projects: cvs diff | wc. sometimes one little change on a line was the result of hours of bughunting while sometimes an apparent huge rewrite was just the result of renaming a function in the entire project, or introducing a macro for some repetitive task. no matter what, check-ins generally indicate work happens.
ich will an sich ne einfach zu erweiternde plattform
protocolwise you have it, languagewise only in LPC and perl, so you may have to put some work into it, if you need it on other platforms.
oh okay, psyc is a platform for the things psyc does today. if you are talking about things psyc isn't doing yet, then it isn't the platform yet, but then probably there aren't any alternatives out there, either.