[GemStone-Smalltalk] A community license for GBJ

[James Foster via GemStone-Smalltalk]

Hi Charles,

> On Dec 1, 2016, at 9:25 AM, Charles Monteiro <charles.monteiro at gmail.com> wrote:
> 
> We are using Jruby in the context of an SOA implementation i.e. a micro service that has persistence needs , there’s no UI involved per se. I’m accustomed to either doing REST or often loading a Java jar into Jruby and using Jruby’s much terser and arguably more ST like syntax to leverage whatever Java comm lib.

As Mariano suggested, it seems that doing REST from Smalltalk might work.

> So trying to wrap Gemstone/S C libs or using CGI is a level of pain that I would not be used to or feel necessary in the context of what’s generally available today. 
> 
> In other words I feel that Gembuilder/J should be available in some sort of open-source , free at least under certain circumstances scenario. Gemstone/S has a lot to offer but and many more may consider it if they could play with it without all that pain. That means folks used to leveraging JVM based languages at least the enterprise devs and therefore that means a Java lib.

I’m still not sure who is in the target audience. Is it passionate Smalltalkers? If so, why are they using Java? Do they find better libraries in Java? Or is it people who don’t know Smalltalk? I don’t have a sense that there are a lot of Java programmers who want to use a Smalltalk object database. (I’m not saying that they don’t exist, just that I haven’t heard of/from them.)

I haven’t got much experience with GBJ but understand that it is not as sophisticated as GBS. I have got a lot of experience with GCI and don’t find it to impose much pain for simpler interactions. Based on your experience with GBJ, GBS, and GCI, what is the value of GBJ over GCI? (I’m not saying there isn’t any, just that I want to understand your use case better.)

> I thought I saw the blurb about licensing and it just directed me to talk to my Gemstone/S Sales rep, but I will check your link.

Yes, email sales at gemtalksystems.com <mailto:sales at gemtalksystems.com> to discuss licensing.

> Re: Mongo and Redis, what I mean to say is that if I want to use either of these DB technologies I can very easily do so and from typical modern ways without constraints. I know you all have to eat but I’m sorry this just reminds me of why Smalltalk got relegated back to the island it was born from, the balloon deflated under all the weight that vendors have burdened it with.

Does the “very easily” part address flattening sophisticated objects into simple documents? Would a GemStone API that looks like Mongo be useful? If so, see https://github.com/dalehenrich/Tugrik <https://github.com/dalehenrich/Tugrik>. 

> Re: my Seaside comment, what I was alluding to was that I am aware one can leverage Gemstone / S from Seaside but that I did not want to use Seaside to front an RPC protocol to my app.

That’s fine; Seaside certainly isn’t the best solution for everything. As Mariano asked, would a simple REST API be appropriate? Alternatively, you could create your own wire protocol from Java to GS/S using sockets. Much of it comes down to what you expect from the database interface. Are you simply looking to store Java objects in an object database? Or are you planning to do sophisticated domain behavior in Smalltalk?

> Recap:
> 
> You all should make Gembuilder/J libs free and should consider that you will make your money once a project deploys a large enough installation of Gemstone/S , never mind consulting fees from onboarded projects.

This isn’t enough to make a persuasive business case, but it is an interesting discussion and I appreciate the input.

~ James

> Hope all is well
> 
> thanks
> 
> Charles
> 
> 
> -- 
> Charles Monteiro
> 
> 
> On December 1, 2016 at 12:10:44 PM, James Foster (smalltalk at jgfoster.net <mailto:smalltalk at jgfoster.net>) wrote:
> 
>> Hi Charles,
>> 
>>> On Dec 1, 2016, at 7:55 AM, Charles Monteiro via GemStone-Smalltalk <gemstone-smalltalk at lists.gemtalksystems.com <mailto:gemstone-smalltalk at lists.gemtalksystems.com>> wrote:
>>> 
>>> given that all Gemstone clients require licenses i.e. VW , VA and GBJ i.e. there are fees associated with any of these paths, therefore it can be said that there's really no real free solution that can be used to test out ideas , a problem that has plagued Smalltalk since folks decided to venture out of the Xerox Parc labs. 
>> 
>> You are right that Cincom and Instantiations both charge for commercial use of their products (as far as I know). You can use the Community Edition license of GemStone/S 64 Bit with other clients, including Pharo and Dolphin, or even Perl, Python, PHP, Ruby, etc., by using the included GCI interface and the client’s FFI.
>> 
>>> Note that it is not the model of any new modern databases i.e. the Mongo and Redis's of this new brave world.
>> 
>> You are right that Mongo and Redis do not map well to Smalltalk objects.
>> 
>>> So how crazy expensive is a GBJ license anyhow ?
>> 
>> To learn more about GemStone licenses, see https://gemtalksystems.com/licensing/ <https://gemtalksystems.com/licensing/>.
>> 
>>> oh, and pls correct me if I have missed something except for telling me to do Seaside dev, since what I would be contemplating would be providing persistence to an app cluster.
>> 
>> What is it about "providing persistence to an app cluster" that makes it incompatible with a web-based UI?
>> 
>>> thanks
>>> 
>>> --
>>> Charles 
>> 
>> Regards,
>> 
>> James
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20161201/40980461/attachment-0001.html>