This all sounds very interesting. What is the idea? Wrap libkrb5 through UFFI or implement it in Smalltalk?
On 10/26/2017 04:38 PM, henry wrote: > A Kerberos effort will have to be a group effort. Sideways to my main > focus and your all’s main focii. > > > - HH > > > On Thu, Oct 26, 2017 at 09:15, henry <he...@callistohouse.club > <%22mailto:he...@callistohouse.club%22>> wrote: > > I think another good service to integrate well to is Elastic Search. > > Of the 4 types of integration, I vote for and step forward to > volunteer to help Kerberos integration in Pharo. What to do? > > > - HH > > > On Thu, Oct 26, 2017 at 09:06, henry <he...@callistohouse.club > <%22%22mailto:he...@callistohouse.club%22%22>> wrote: > > I try posting with a smaller image. > > ""hubbub.jpg"" > > - HH > > > ——— Original Message ——— > Subject: Re: [Pharo-users] Smalltalk Argument > Local Time: October 26, 2017 8:52 AM > UTC Time: October 26, 2017 12:52 PM > From: he...@callistohouse.club > To: p...@highoctane.be <p...@highoctane.be>, Any question > about pharo is welcome <pharo-users@lists.pharo.org> > > Perhaps not, or not yet. Perhaps it is the communications > foundation for an always-on cloud/bigData control layer. > > I would position ParrotTalk as a Kerberos transport. > ParrotTalk does 2048-bin key negotiation and subsequent > encryption/encoding, both user-supplied. > > Please see the attached diagram, co-locating ParrotTalk > with my other components. > > ParrotTalk does not do user authentication/authorization. > Which means to me that I should consider Kerberos > authorization/authentication to establish as an > integratable transport to play in bigData. > > This means you still need a Kerberos client and I need a > Kerberos client. How do we start? > > - HH > > PS: I did much work integrating Kafka into a framework. I > was thinking of inserting msg sending replication to a > partition count of replicate queues for sending and > receiving Hubbub traffic, thus inserting right where > Kerberos is in the diagram. I would love to see client > coupling for Kerberos, Kafka and Hadoop, while I figure > out proper security to make that group happy with this as > a possible control layer solution, forking off jobs. > > > On Thu, Oct 26, 2017 at 03:14, p...@highoctane.be > <p...@highoctane.be > <%22%22%22mailto:p...@highoctane.be%22%22%22>> wrote: > > Sure. Current main issue is to have Pharo work with > Kerberos as secured Hadoop uses the UGI > (UserGroupInformation) thing and that is a black hole > of crypto things. > > How would you see ParrotTalk work? > > I made a XmppTalk thing (binding for libstrophe) for > having Pharo images and other stuff talk together > (currently using OpenFire/Gajim/Profanity) FWIW > > See > > https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1UaX5ikEU/edit?usp=sharing > > <%22%22%22https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1UaX5ikEU/edit?usp=sharing%22%22%22> > > > libstrophe does the SSL thing under the hood (using > OpenSSL) and is actively maintained. > > https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c > > <%22%22%22https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c%22%22%22> > > > And I currently work with Kafka so, Pharo as a > consumer or producer, sure am interested. But need > Kerberos support. > > Tell me more about your vision. Even better, draw it > in some way :-) > > Phil > > > On Thu, Oct 26, 2017 at 8:43 AM, henry > <he...@callistohouse.club > <%22%22%22mailto:he...@callistohouse.club%22%22%22>> > wrote: > > This is a goal of ParrotTalk, to bring > bit-compatible communications to Squeak, Pharo and > Java. This is not an invocation bridge you speak > of but a communications bridge to be able to run > against Hadoop or whichever big data needs > integration with (Kafka). I had hoped it might be > adopted for such. Yet again this is not exactly > what you were looking for but yet interesting > perhaps? > > > - HH > > > On Thu, Oct 26, 2017 at 02:17, p...@highoctane.be > <%22%22%22mailto:p...@highoctane.be%22%22%22> > <p...@highoctane.be> wrote: > > I like that piece a lot, seeing exactly the > described situation in large enterprises. > > I made a strategic decision to go with Pharo > for the long run for my solutions because it > is a stable base on which to build (ok, there > are evolutions, but fundamentally, I can rely > on it being under control and can maintain > solutions in a version). > > The rationale is that at a deep level I am > really fed up with having to deal with > accidental complexity (now having to deal with > Spark/Scala/sbt/Java/maven stuff) that makes > the dev focus 80% technology drag and 20% net > business contribution. > > One key thing is that a team needs guidance > and Smalltalk makes it easier due to well > known ways of doing things. > > Now we miss the boat on mobile and bigdata, > but this is solvable. > > If we had an open Java bridge (and some people > in the community have it for Pharo but do not > open source it - so this is eminently doable) > + Pharo as an embeddable piece (e.g. like Tcl > and Lua) and not a big executable we would > have a way to embed Pharo in a lot of places > (e.g. in the Hadoop ecosystem where fast > starting VMs and small footprint would make > the cluster capacity x2 or x3 vs uberjars all > over the place) this would be a real disruption. > > Think about being able to call Pharo from > JNA https://github.com/java-native-access/jna > the same way we use C with UFFI. > > Smalltalk argument for me is that it makes > development bearable (even fun and enjoyable > would I say) vs the other stacks. That matters. > > Phil >
