What is needed is a target. A stable release that will not change. For the mainstream this happens after successful safecoin release. For the enthusiasts at beta. Until then changes should be expected as development continues and new aspects are encountered.
Yes I think we all agree, but sometimes you need steps to the target, whatever that is. so we iterate and do so in great detail with each step. I think we are all saying the same or similar, but it’s not possible to easily say next step is launch and just don’t change as nobody knows what 2 steps from now is, could be launch, could be more fixes etc. So we set out next target in terms of alpha/beta and use testnets as steps to those, with weekly updates to show even more granularity.
Sorry to revive this topic, but the number of objects created for files in safe sites are even greater than I indicated in my earlier post because, additionally, there is one service object (MD with tag 15002) generated for each file. I have noticed this in a local safe network based on Alpha 2.
IMO this relation arity is not right because it creates a big waste of MD objects. Previously (with SDs) there was only one service per site, which was more logical.
Updated table is the following:
Previous implementation | New implementation | |
---|---|---|
Cost of small file | 0 units | 3 units |
Cost of medium file | 3 units | 6 units |
(neglecting directory and service which were shared by several files in previous implementation).
Another problem is that all the sites of a user share the same root directory (= container), meaning that they charge the same number of entries limit. IMO each site should have its own container, so that they can each have their own number of entries limit.
The service could be associated with this new type of container, which would also solve the problem about the number of service objects created.