I have no idea which is best. For being able to say we use industry standard Kerberos, calling an accepted implementation seems wise, like OpenSSL support.

- HH

On Thu, Oct 26, 2017 at 11:39, Paulo R. Dellani <dellani@pobox.com> wrote:

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 <henry@callistohouse.club> 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 <henry@callistohouse.club> wrote:

I try posting with a smaller image.

- 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: henry@callistohouse.club

To: phil@highoctane.be <phil@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, phil@highoctane.be <phil@highoctane.be> 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

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

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 <henry@callistohouse.club> 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, phil@highoctane.be < phil@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