elective-stereophonic
elective-stereophonic
NRS v1.6.2
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Nxt Client: Nxt 1.11.15

Pages: 1 ... 3 4 [5] 6 7 ... 18  All

Author Topic: NRS v1.6.2  (Read 71383 times)

Klokan

  • Sr. Member
  • ****
  • Karma: +28/-5
  • Offline Offline
  • Posts: 286
    • View Profile
Re: NRS v1.6.2
« Reply #80 on: November 04, 2015, 06:30:51 pm »

Will be any statement from core devs about this situation? Why API calls has been "broken" and if this was really necessary? When we can expect version 1.6.3? I'm just waiting with updating of my nodes from 1.5.15 into 1.6 series due to unclear situation and I'll probably be not the only one.
Logged

yassin54

  • Hero Member
  • *****
  • Karma: +240/-14
  • Offline Offline
  • Posts: 2503
  • I am Homer, Sorry my english is Bad!!
    • View Profile
Re: NRS v1.6.2
« Reply #81 on: November 04, 2015, 06:45:16 pm »

Will be any statement from core devs about this situation? Why API calls has been "broken" and if this was really necessary?
Same here. :)

SamIbandii

  • Full Member
  • ***
  • Karma: +10/-3
  • Offline Offline
  • Posts: 109
  • do great things while they are small (Lao Tzu)
    • View Profile
Re: NRS v1.6.2
« Reply #82 on: November 04, 2015, 07:53:30 pm »

Will be any statement from core devs about this situation? Why API calls has been "broken" and if this was really necessary? When we can expect version 1.6.3? I'm just waiting with updating of my nodes from 1.5.15 into 1.6 series due to unclear situation and I'll probably be not the only one.


Same with me.
But I 'm sure the core devs are already working on these issues.
Logged

barbierir

  • Sr. Member
  • ****
  • Karma: +36/-2
  • Offline Offline
  • Posts: 316
    • View Profile
Re: NRS v1.6.2
« Reply #83 on: November 04, 2015, 08:17:09 pm »

The silence is almost certainly due to the fact they're very busy working to solve the issues, otherwise there would have been official communications by now
Logged

farl4bit

  • Global Moderator
  • Hero Member
  • *****
  • Karma: +210/-45
  • Offline Offline
  • Posts: 3463
    • View Profile
    • Blockchain Twitter
Re: NRS v1.6.2
« Reply #84 on: November 04, 2015, 10:10:27 pm »

The silence is almost certainly due to the fact they're very busy working to solve the issues, otherwise there would have been official communications by now

I hope so. Good communication is key in such a hyper market as crypto.
Logged

testdruif

  • Full Member
  • ***
  • Karma: +71/-1
  • Offline Offline
  • Posts: 223
    • View Profile
Re: NRS v1.6.2
« Reply #85 on: November 04, 2015, 10:15:52 pm »

A quick update:

Solutions are being presented and discussed.
At this moment a few options are on the table and need to be further explored.
Logged
**Necessity is the mother of invention**
NXT-NNGD-V8TN-3MZR-DWWBE
https://arguseyes.net

yassin54

  • Hero Member
  • *****
  • Karma: +240/-14
  • Offline Offline
  • Posts: 2503
  • I am Homer, Sorry my english is Bad!!
    • View Profile
Re: NRS v1.6.2
« Reply #86 on: November 04, 2015, 10:26:44 pm »

A quick update:

Solutions are being presented and discussed.
At this moment a few options are on the table and need to be further explored.
Thanks for Update!!  :)

DoTheNXT

  • Jr. Member
  • **
  • Karma: +3/-0
  • Offline Offline
  • Posts: 50
    • View Profile
Re: NRS v1.6.2
« Reply #87 on: November 05, 2015, 06:06:18 am »

Is this version only for winx64 systems?

The Windows installer bundles only Java 64 bit. In case you need to run NXT on a 32 bit workstation you can install Java 32 bit separately and configure run.bat to use it instead of the jre bundled with the installation. If you like we can provide a procedure for this.
It will be fine
Logged

maddy83

  • Sr. Member
  • ****
  • Karma: +108/-50
  • Offline Offline
  • Posts: 292
    • View Profile
Re: NRS v1.6.2
« Reply #88 on: November 05, 2015, 07:04:49 am »

Regarding the API change, rest assured that this decision was not taken lightly.
We will post a detailed explanation of the reasons for these changes and detailes about more upcoming changes - tomorrow.

When is this coming?

I'm getting in touch with everyone involved hoping to bring them together.
I'm hoping that at the end of the discussion we can walk away with a clear set of agreements that can be shared (and ofc discussed) with everyone and all developers.

There was already an agreement in place which was made after backwards compability was broken the last time.

Solutions are being presented and discussed.
At this moment a few options are on the table and need to be further explored.

What "solutions" are being discussed? Why not just change the default value of includeAssetInfo parameter to true, and release 1.6.3 with no other changes, if that is what broke it?
Logged
Will do small programming tasks for NXT. PM me!

crackers

  • Full Member
  • ***
  • Karma: +20/-7
  • Offline Offline
  • Posts: 243
    • View Profile
Re: NRS v1.6.2
« Reply #89 on: November 05, 2015, 02:46:15 pm »

It would be helpful to note any depreciated/obsoleted API's.

I discovered that my scripts were failing on getAccountTransactions when it has been moved to getBlockchainTransactions

Thanks
Logged
www.xpool.ca - NXT Multipool - Donate: NXT-DJGG-TNA9-2SC3-FL9U9 - Support

coretechs

  • Sr. Member
  • ****
  • Karma: +161/-1
  • Offline Offline
  • Posts: 436
    • View Profile
Re: NRS v1.6.2
« Reply #90 on: November 05, 2015, 05:58:11 pm »

I've had to deal with API changes but I'm probably one of the few people who doesn't mind.  I think one of the easiest ways to resolve this is to simply publish an "Incompatible Changes" section/list in the change logs.
Logged
https://ardorportal.org - Ardor blockchain explorer | https://nxtportal.org - Nxt blockchain explorer | http://bitcoindoc.com - The Rise and Rise of Bitcoin
ARDOR-T43P-R2K9-8W79-9W2AL | NXT-WY9K-ZMTT-QQTT-3NBL7

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: NRS v1.6.2
« Reply #91 on: November 06, 2015, 08:44:04 am »

Posting publicly our detailed explanation of the reasons behind the 1.6 API changes, and the conclusions reached:

The reason we are bundling quite a few incompatible API changes in 1.6 is exactly because it is an optional update, not requiring a hard fork, and this was emphasized in the first 1.6.0e changelog. Some of our APIs, such as getAccount and getAsset, date back from before the switch to using a database, when we kept all objects in memory and were doing rescans. What was efficient and simple to do then is no longer true now. I wish we could have started with a perfectly designed APIs, but in a real world, APIs do need to change. Yes, I have heard the suggestion about versioned APIs, but we don't have the development resources to maintain such versioning, and it would be an overkill for a change like the include parameter defaults. Even if we did have versioned APIs, for how many versions back would you expect that they should be maintained? If for two versions, this is the same as what you get by allowing both 1.5 and 1.6 to coexist on the network until the next hard fork, if you need the old version stay with 1.5.

The database is our bottleneck now, and the motivation behind most API changes has been that the defaults should give you the best performance. An API user should be able to call getAccount, getAsset, and getAccountAssets, with just the corresponding object id's, without digging in the documentation or reading the code to figure out what extra options to add to avoid performance problems. In 1.5, by default getAccount also returns asset balances, currency balances, lessors, and effective balance. Those are expensive to get, and the API user certainly does not need all of them all the time. The getAsset call by default counts total number of trades, transfers, and shareholders for the asset. The includeCounts parameter was added a few releases back to allow optimizing the performance of getAsset, but at some point the default of true should be changed to false, because it makes the API difficult to learn and use if for every getAsset call you need to add includeCounts=false in order to get acceptable performance. It will still work without it, but performance will suffer, and the user will complain that everything is slow.

In 1.7, we are adding singleton assets, which are like regular assets in all respects but limited to quantity of 1, and at a much lower issuance fee, 1 NXT. This will have the side effect that the asset table can increase in size a lot, as users can start creating a lot of those singleton assets (intended to use as tradeable tokens representing a single object). Thinking about the performance consequences of this made me review the queries to the asset table, and is one of the reasons for the includeAssetInfo default value change.

There are such include parameters in very many API calls, and in most of them they have been added after the API was first published, to allow improving the performance. Until now, there defaults have been set to be consistent with the API behavior before they were added, because this was done at minor releases where we did not want to introduce incompatible changes. But this cruft all adds up, and this is why we looked at 1.6 as the best time to globally fix such defaults, improve consistency, optimize performance, and make the API easier to learn and use.

We had long internal discussions about the issue, also involving the SuperNet developers. We had a proposal for a workaround using a filter, supplying different default parameter values based on configuration in nxt.properties, but this was not considered useful by the SuperNet team so I am not going to implement it. There is no other feasible technical solution. All clients of the APIs that are affected by the changes must be updated, and we will document in details which APIs have been changed to make that easier. There will be no reversal in 1.6.3.

The 1.6.1e changelog did have an "incompatible changes" section, and the rest of the incompatible changes were also included in the 1.6.2 changelog, but now we realize that in practice this is not sufficient. To improve communication to potentially affected parties, we plan to setup mailing lists for such notifications, and make sure to announce important changes as early as pratically possible in the future.

Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Karma: +816/-81
  • Offline Offline
  • Posts: 1610
    • View Profile
Re: NRS v1.6.2
« Reply #92 on: November 06, 2015, 08:45:20 am »

This is a summary of the incompatible API changes from 1.5 to 1.6.

If you use any of the following APIs, and require the additional fields returned
when the corresponding includeX parameters are set to true, make sure these
parameters are explicitly added with a value of true to the API call. By default
their values are now false, which results in the corresponding additional fields
not being returned unless explicitly requested. If the additional fields are not
needed, do not request them as this will only hurt performance.

getAccount:
default values of includeAssets, includeCurrencies, includeEffectiveBalance,
includeLessors have been changed to false

getAccountAssets:
new includeAssetInfo parameter has been added, default false

getAccountCurrencies:
new includeCurrencyInfo parameter has been added, default false

getAccountExchangeRequests:
new includeCurrencyInfo parameter has been added, default false

getAccountTaggedData:
default value of includeData has been changed to false

getAllAssets:
default value of includeCounts has been changed to false

getAllCurrencies:
default value of includeCounts has been changed to false

getAllExchanges:
default value of includeCurrencyInfo has been changed to false

getAllTaggedData:
default value of includeData has been changed to false

getAllTrades:
default value of includeAssetInfo has been changed to false

getAsset:
default value of includeCounts has been changed to false

getAssets:
default value of includeCounts has been changed to false

getAssetsByIssuer:
default value of includeCounts has been changed to false

getAssetTransfers:
default value of includeAssetInfo has been changed to false

getBalance:
default value of includeEffectiveBalance has been changed to false

getChannelTaggedData:
default value of includeData has been changed to false

getCurrencies:
default value of includeCounts has been changed to false

getCurrenciesByIssuer:
default value of includeCounts has been changed to false

getCurrency:
default value of includeCounts has been changed to false

getCurrencyTransfers:
default value of includeCurrencyInfo has been changed to false

getDGSGood:
default value of includeCounts has been changed to false

getDGSGoods:
default value of includeCounts has been changed to false

getExchanges:
default value of includeCurrencyInfo has been changed to false

getExchangesByExchangeRequest:
default value of includeCurrencyInfo has been changed to false

getExchangesByOffer:
default value of includeCurrencyInfo has been changed to false

getExpectedAssetTransfers:
new includeAssetInfo parameter has been added, default false

getExpectedCurrencyTransfers:
new includeCurrencyInfo parameter has been added, default false

getState:
default value of includeCounts has been changed to false

getTrades:
default value of includeAssetInfo has been changed to false

searchAssets:
default value of includeCounts has been changed to false

searchCurrencies:
default value of includeCounts has been changed to false

searchTaggedData:
default value of includeData has been changed to false


The additional fields that the includeX parameters add when set to true are:

includeAssetInfo: asset name and decimals

includeCounts: for assets, number of trades, transfers, and shareholders;
for currencies, number of exchanges and number of transfers

includeCurrencyInfo: currency name, code, type, decimals, issuanceHeight,
issuerAccount

includeData: the actual data bytes of the tagged data

includeEffectiveBalance: the effective and guaranteed balances of the account

includeAssets, includeCurrencies, includeLessors: for the getAccount API,
respectively the asset balances, currency balances, and lessors to the account



The getAccountTransactions and getAccountTransactionIDs APIs, deprecated in 1.5
have been removed in 1.6. Use getBlockchainTransactions instead and make sure
to handle correctly the phased transactions.



Any APIs that accept an object id such as account, asset, or currency, but do
not need to retrieve the actual object, no longer check for its existence.
As a result, instead of returning an error when supplied with an unknown id,
they will return an empty result.



Asset transfers to the Genesis account are now treated as deletion of asset
shares. The quantityQNT in the asset JSON returned by APIs such as getAsset
now corrects for such share deletion. The original asset quantity issued is
returned as initialQuantityQNT in the asset JSON. For the same reason,
calling getAssetTransfers with the Genesis account as parameter can no longer
be used to determine the total number of deleted asset shares. Use the above
quantityQNT and initialQuantityQNT fields to find the initial and the currently
available total asset shares instead.
« Last Edit: November 23, 2015, 01:50:33 pm by Jean-Luc »
Logged
GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

blackyblack1

  • Hero Member
  • *****
  • Karma: +165/-82
  • Offline Offline
  • Posts: 1763
    • View Profile
Re: NRS v1.6.2
« Reply #93 on: November 06, 2015, 09:09:11 am »

Quote
and the motivation behind most API changes has been that the defaults should give you the best performance. An API user should be able to call getAccount, getAsset, and getAccountAssets, with just the corresponding object id's, without digging in the documentation or reading the code to figure out what extra options to add to avoid performance problems.
This does not sound very logical. Average users are using default NXT client which is maintained by people knowing a lot about NXT API and aware of performance issues to add necessary switches. Other users are using NRS as a platform and they will definitely prefer backwards compatibility over "best performance". They will better have slower but working system after update than totally broken fast system.
Logged

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: NRS v1.6.2
« Reply #94 on: November 06, 2015, 02:10:38 pm »


We had long internal discussions about the issue, also involving the SuperNet developers. We had a proposal for a workaround using a filter, supplying different default parameter values based on configuration in nxt.properties, but this was not considered useful by the SuperNet team so I am not going to implement it. There is no other feasible technical solution. All clients of the APIs that are affected by the changes must be updated, and we will document in details which APIs have been changed to make that easier. There will be no reversal in 1.6.3.

The 1.6.1e changelog did have an "incompatible changes" section, and the rest of the incompatible changes were also included in the 1.6.2 changelog, but now we realize that in practice this is not sufficient. To improve communication to potentially affected parties, we plan to setup mailing lists for such notifications, and make sure to announce important changes as early as pratically possible in the future.
There was no discussion with the SuperNET team about the 1.6.2 breaking all the installed base. The only "discussion" happened after I complained about it not being backward compatible. And this "discussion" was basically a confirmation that the promise of backward compatibility that was made last year is not being honored.

There have been many customer support issues due to the breaking of the API and a lot of unreported cases where the customers just stop using SuperNET (and NXT)

I have been assured that with each NXT release that there will likely NOT be any backward compatibility of the API, which means anything that uses it will likely break and need unknown amounts of testing, requalification and of course customer support and field update issues.

It is not possible to deploy a large scale system using a "platform" that isnt backward compatible due to the breaking of all the ALREADY installed and running systems. With decentralized systems it is not possible for centrally force an update on users. Just look at some of the versions NXT peers are still running. Therefore anything that is guaranteed to break is certainly not worth spending marketing dollars to acquire the installed base for.

The NXT devs lack a fundamental understanding about business reality and I am extremely disappointed in the breaking of the promise to keep things backward compatible. The ONLY exception is if there is an attack vector. Local node performance is not any excuse.

Due to this, I am rethinking my reliance on NXT for SuperNET. I have quite a lot of code that takes all my time to create and to be assured that I will have to keep reworking it forever due to backward compatibility breaking with each release. This is not practical for me.

So, NXT will have a more efficient API with much fewer users. That is the effect of this breaking of the backward compatibility promise.

Anyway, the first effect of all this is that ALL of my projects will be delayed. I will wait for NXT API to stabilize before I waste my time. The most likely scenario is that I will just remove all dependency on NXT and put whatever functions I need into BTCD.

James

tl:dr it is a MAJOR breach of trust as far as I am concerned that the API backward compatibility promise has been violated and I cannot rely on NXT for any important SuperNET functions.
Logged
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: NRS v1.6.2
« Reply #95 on: November 06, 2015, 02:16:37 pm »

This is a summary of the incompatible API changes from 1.5 to 1.6.

If you use any of the following APIs, and require the additional fields returned
when the corresponding includeX parameters are set to true, make sure these
parameters are explicitly added with a value of true to the API call. By default
their values are now false, which results in the corresponding additional fields
not being returned unless explicitly requested. If the additional fields are not
needed, do not request them as this will only hurt performance.

getAccount:
default values of includeAssets, includeCurrencies, includeEffectiveBalance,
includeLessors have been changed to false

getAccountAssets:
new includeAssetInfo parameter has been added, default false

getAccountCurrencies:
new includeCurrencyInfo parameter has been added, default false

getAccountExchangeRequests:
new includeCurrencyInfo parameter has been added, default false

getAccountTaggedData:
default value of includeData has been changed to false

getAllAssets:
default value of includeCounts has been changed to false

getAllCurrencies:
default value of includeCounts has been changed to false

getAllExchanges:
default value of includeCurrencyInfo has been changed to false

getAllTaggedData:
default value of includeData has been changed to false

getAllTrades:
default value of includeAssetInfo has been changed to false

getAsset:
default value of includeCounts has been changed to false

getAssets:
default value of includeCounts has been changed to false

getAssetsByIssuer:
default value of includeCounts has been changed to false

getAssetTransfers:
default value of includeAssetInfo has been changed to false

getBalance:
default value of includeEffectiveBalance has been changed to false

getChannelTaggedData:
default value of includeData has been changed to false

getCurrencies:
default value of includeCounts has been changed to false

getCurrenciesByIssuer:
default value of includeCounts has been changed to false

getCurrency:
default value of includeCounts has been changed to false

getCurrencyTransfers:
default value of includeCurrencyInfo has been changed to false

getDGSGood:
default value of includeCounts has been changed to false

getDGSGoods:
default value of includeCounts has been changed to false

getExchanges:
default value of includeCurrencyInfo has been changed to false

getExchangesByExchangeRequest:
default value of includeCurrencyInfo has been changed to false

getExchangesByOffer:
default value of includeCurrencyInfo has been changed to false

getExpectedAssetTransfers:
new includeAssetInfo parameter has been added, default false

getExpectedCurrencyTransfers:
new includeCurrencyInfo parameter has been added, default false

getState:
default value of includeCounts has been changed to false

getTrades:
default value of includeAssetInfo has been changed to false

searchAssets:
default value of includeCounts has been changed to false

searchCurrencies:
default value of includeCounts has been changed to false

searchTaggedData:
default value of includeData has been changed to false


The additional fields that the includeX parameters add when set to true are:

includeAssetInfo: asset name and decimals

includeCounts: for assets, number of trades, transfers, and shareholders;
for currencies, number of exchanges and number of transfers

includeCurrencyInfo: currency name, code, type, decimals, issuanceHeight,
issuerAccount

includeData: the actual data bytes of the tagged data

includeEffectiveBalance: the effective and guaranteed balances of the account

includeAssets, includeCurrencies, includeLessors: for the getAccount API,
respectively the asset balances, currency balances, and lessors to the account



The getAccountTransactions and getAccountTransactionIDs APIs, deprecated in 1.5
have been removed in 1.6. Use getBlockchainTransactions instead and make sure
to handle correctly the phased transactions.



Any APIs that accept an object id such as account, asset, or currency, but do
not need to retrieve the actual object, no longer check for its existence.
As a result, instead of returning an error when supplied with an unknown id,
they will return an empty result.
THIS post is the first time I see the full extent of the changes to existing API. No wonder all websites and apps using NXT are broken.

With this many changes and no direct communication, it is no surprise that everything broke. The local performance of API is not anything that should enable a CENTRALLY decided breaking of backward compatibility.

But there has been ZERO changes based on my feedback as I am not important enough to listen to. Neither are any of the other devs.

So I say goodbye

James
Logged
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

martismartis

  • Hero Member
  • *****
  • Karma: +73/-10
  • Offline Offline
  • Posts: 1237
    • View Profile
Re: NRS v1.6.2
« Reply #96 on: November 06, 2015, 02:35:13 pm »

Sorry, I'm not a coder and correct me if I'm wrong. Is it impossible to do, that old API could coexist with new API in every new version? I understand Jean-Luc, he is working hard to improve performance and I understand other devs, who need to remake their code to work with the latest releases. Leave all old API, what was created with the new versions. A lot of companies still using Windows XP, not upgrading it to the newest versions, as it was tested and running for their needs. Maybe performance is poorer, but it is working. Let other devs decide which API to use for their projects: with better performance and features or with old goodies, which do the job:)

P.S. I'd like to ask to calm both sides, sit together and talk about it :) No need to panic. Still hope that 1.6.3 could solve this problem :)
Logged

Cassius

  • Hero Member
  • *****
  • Karma: +207/-18
  • Offline Offline
  • Posts: 2459
  • Rather be a pirate than join the navy
    • View Profile
Re: NRS v1.6.2
« Reply #97 on: November 06, 2015, 02:36:51 pm »

This is extremely unfortunate. Watching to see how this develops.
Logged
I head up content for BitScan, crypto business hub.

barbierir

  • Sr. Member
  • ****
  • Karma: +36/-2
  • Offline Offline
  • Posts: 316
    • View Profile
Re: NRS v1.6.2
« Reply #98 on: November 06, 2015, 02:37:09 pm »

I really hope the Nxt dev team will change their mind and make 1.6.3 backward compatible. This is a very serious crisis and if this issue doesn't get resolved Nxt will lose one of its main 3rd party projects. I'm convinced that 99% of the community agrees with this position. And in case of doubt we have the voting feature and this is a damn use case for it!!!
Logged

_mr_e

  • Hero Member
  • *****
  • Karma: +88/-18
  • Offline Offline
  • Posts: 956
    • View Profile
Re: NRS v1.6.2
« Reply #99 on: November 06, 2015, 02:38:36 pm »

Developing a "platform" that doesn't support backwards compatibility is a total joke. Why is this even an argument?
Logged
Pages: 1 ... 3 4 [5] 6 7 ... 18  All
 

elective-stereophonic
elective-stereophonic
assembly
assembly