Possible external interface to Environments?

Hi Steve,

We have talked about the possibility of doing so, but have not yet put it on the todo list.  There are some new potential features coming down the pipe that would help with your issue, but we have only just begun to implement some of these on an internal version of the product.  For example, we are looking at ways to automatically detect and import new environments and installations that are available in the default locations.  We have not considered an ini file/registry model, though we are considering using a lightweight database, such as SQLite , to store the Environments model.

Thanks,

Bob

On Tuesday, April 24, 2018 at 12:18:57 PM UTC-4, Steven LaFavor wrote:

In looking at the Environments application, I can see possibilities for it replacing our existing internal processes of running different development image versions of our application which we now control using a combination of powershell and batch scripts.

While it would be possible to have the users manually add the environments after copying them locally to their machines, it would be nice if there was a way to programatically add them outside of Smalltalk.

Since the Environments application uses the object dumper/loader to store its settings currently, this is tough. (yes I could externally call a smalltalk class, yada yada yada)

Is there any plan to release the code of the Environments application for user modification or possible change the storage to an ini file/registry model?

*Steve*

We have considered XML, but not JSON.  As we are adding JSON support in the upcoming  9.1 release, this is something to consider.  The DB would not be  a problem since we build and ship the SQLite DLL/SO with every version of VA Smalltalk. Thanks for your input!

Bob

On Wednesday, April 25, 2018 at 6:05:48 PM UTC-4, Steven LaFavor wrote:

For the information that it seems to store in its app, it could store its values in a simple XML or JSON file.  A database could be a bit of overkill here which might introduce a possible point of failure (drivers, configuration, etc.)

On Tuesday, April 24, 2018 at 2:44:35 PM UTC-5, Bob Brodd wrote:

Hi Steve,

We have talked about the possibility of doing so, but have not yet put it on the todo list.  There are some new potential features coming down the pipe that would help with your issue, but we have only just begun to implement some of these on an internal version of the product.  For example, we are looking at ways to automatically detect and import new environments and installations that are available in the default locations.  We have not considered an ini file/registry model, though we are considering using a lightweight database, such as SQLite , to store the Environments model.

Thanks,

Bob

On Tuesday, April 24, 2018 at 12:18:57 PM UTC-4, Steven LaFavor wrote:

In looking at the Environments application, I can see possibilities for it replacing our existing internal processes of running different development image versions of our application which we now control using a combination of powershell and batch scripts.

While it would be possible to have the users manually add the environments after copying them locally to their machines, it would be nice if there was a way to programatically add them outside of Smalltalk.

Since the Environments application uses the object dumper/loader to store its settings currently, this is tough. (yes I could externally call a smalltalk class, yada yada yada)

Is there any plan to release the code of the Environments application for user modification or possible change the storage to an ini file/registry model?

*Steve*

On Friday, April 27, 2018 at 11:12:36 AM UTC-7, Bob Brodd wrote:

We have considered XML, but not JSON.  As we are adding JSON support in the upcoming  9.1 release, this is something to consider.  The DB would not be  a problem since we build and ship the SQLite DLL/SO with every version of VA Smalltalk. Thanks for your input!

In my opinion, XML is a horror. (More precisely, has become a horror.)

JSON is a better choice, although STON may be the best choice.

Please avoid opaque storage models. And feel free to count my vote for making the Smalltalk code available in the standard distribution. I can't think of a reason to exclude it, especially since it was developed by Instantiations and not by IBM.

 

Bob

On Wednesday, April 25, 2018 at 6:05:48 PM UTC-4, Steven LaFavor wrote:

For the information that it seems to store in its app, it could store its values in a simple XML or JSON file.  A database could be a bit of overkill here which might introduce a possible point of failure (drivers, configuration, etc.)

On Tuesday, April 24, 2018 at 2:44:35 PM UTC-5, Bob Brodd wrote:

Hi Steve,

We have talked about the possibility of doing so, but have not yet put it on the todo list.  There are some new potential features coming down the pipe that would help with your issue, but we have only just begun to implement some of these on an internal version of the product.  For example, we are looking at ways to automatically detect and import new environments and installations that are available in the default locations.  We have not considered an ini file/registry model, though we are considering using a lightweight database, such as SQLite , to store the Environments model.

Thanks,

Bob

On Tuesday, April 24, 2018 at 12:18:57 PM UTC-4, Steven LaFavor wrote:

In looking at the Environments application, I can see possibilities for it replacing our existing internal processes of running different development image versions of our application which we now control using a combination of powershell and batch scripts.

While it would be possible to have the users manually add the environments after copying them locally to their machines, it would be nice if there was a way to programatically add them outside of Smalltalk.

Since the Environments application uses the object dumper/loader to store its settings currently, this is tough. (yes I could externally call a smalltalk class, yada yada yada)

Is there any plan to release the code of the Environments application for user modification or possible change the storage to an ini file/registry model?

*Steve*

Hi Guys,

How about keeping the object dumper/loader stuff and adding a small Smalltalk program to edit them.

Lou

On Monday, May 7, 2018 at 2:12:26 AM UTC-4, Joachim Tuchel wrote:

Richard,

+1 on XML.
They once said XML was both human and machine readable. These days, it is neither. It just burns lots of cycles and requires extremely expensive tools to make it human approachable to at least some degree. A classic example of a complete failure that is carried on just for the sake of not having to admit it was a bad idea.
Not sure I trust in JSON to not be forked into hundreds of dialects though...

Joachim


Am Donnerstag, 3. Mai 2018 20:44:10 UTC+2 schrieb Richard Sargent:

On Friday, April 27, 2018 at 11:12:36 AM UTC-7, Bob Brodd wrote:

We have considered XML, but not JSON.  As we are adding JSON support in the upcoming  9.1 release, this is something to consider.  The DB would not be  a problem since we build and ship the SQLite DLL/SO with every version of VA Smalltalk. Thanks for your input!

In my opinion, XML is a horror. (More precisely, has become a horror.)

JSON is a better choice, although STON may be the best choice.

Please avoid opaque storage models. And feel free to count my vote for making the Smalltalk code available in the standard distribution. I can't think of a reason to exclude it, especially since it was developed by Instantiations and not by IBM.

 

Bob

On Wednesday, April 25, 2018 at 6:05:48 PM UTC-4, Steven LaFavor wrote:

For the information that it seems to store in its app, it could store its values in a simple XML or JSON file.  A database could be a bit of overkill here which might introduce a possible point of failure (drivers, configuration, etc.)

On Tuesday, April 24, 2018 at 2:44:35 PM UTC-5, Bob Brodd wrote:

Hi Steve,

We have talked about the possibility of doing so, but have not yet put it on the todo list.  There are some new potential features coming down the pipe that would help with your issue, but we have only just begun to implement some of these on an internal version of the product.  For example, we are looking at ways to automatically detect and import new environments and installations that are available in the default locations.  We have not considered an ini file/registry model, though we are considering using a lightweight database, such as SQLite , to store the Environments model.

Thanks,

Bob

On Tuesday, April 24, 2018 at 12:18:57 PM UTC-4, Steven LaFavor wrote:

In looking at the Environments application, I can see possibilities for it replacing our existing internal processes of running different development image versions of our application which we now control using a combination of powershell and batch scripts.

While it would be possible to have the users manually add the environments after copying them locally to their machines, it would be nice if there was a way to programatically add them outside of Smalltalk.

Since the Environments application uses the object dumper/loader to store its settings currently, this is tough. (yes I could externally call a smalltalk class, yada yada yada)

Is there any plan to release the code of the Environments application for user modification or possible change the storage to an ini file/registry model?

*Steve*