iitc-project / ingress-intel-total-conversion

ingress.com/intel total conversion user script with some new features. Should allow easier extension of the intel map.
http://iitc.jonatkins.com/
ISC License
991 stars 553 forks source link

Is there anyone from developers? #1301

Open SignFinder opened 5 years ago

SignFinder commented 5 years ago

Is there anyone from developers? The project is creeping into third-party repositories, and here there is no one at least to receive someone pull requests.

Sync is broken, there is working fix to fix it https://github.com/IITC-CE/ingress-intel-total-conversion/commit/115825f80c1ab93c5f25b4fdd9ad182bbdd87189 but here nobody can approve pull requests etc.

johnd0e commented 5 years ago

but here nobody can approve pull requests etc.

For many years, actually. No one of former developers is still interested in the project, so just consider it abandoned.

skregas commented 4 years ago

@johnd0e What about handing the project over to interested parties? Would you give your blessing to a fork that resumes development?

I greatly appreciate this tool and would like to see its growth supported. Thanks for all the work you've done on the project

johnd0e commented 4 years ago

@skregas Why you ask me? I am not related with iitc-project.

If you are looking for forks then give a try to iitc-ce.

MysticJay commented 3 years ago

@Xelio Can you shed some light on the design of SYNC? Please PM me.

Xelio commented 3 years ago

@Xelio Can you shed some light on the design of SYNC? Please PM me.

It was built around Google Realtime API, Realtime API was deprecated years ago. And I've forgot how I design the SYCN after so many years....

MysticJay commented 3 years ago

@Xelio Well, SYNC has been taken forward into IITC-CE. The authorizer has been adjusted since then and the plugin is working.

Still we see a lot of code, that seem not to make sense, unless you had a bigger picture in mind. The existing code might then only be a subset to get the first version working One thing that comes to my mind is "Collaboration/sharing" which would require to use an other set of access data. So its not about the deep details, but "what were your ideas (for the future)?"

If you do not want to look at the "new" code, even hints from the old versions can be helpful. In the end there might be a refactoring of SYNC. But we neither want to break existing functionality nor re-invent the wheel. Take your time and thanks in advance

Xelio commented 3 years ago

@MysticJay I took a quick look on my original code

First there is a function to let other plugin(pluginName) to register their data(fieldName) to sync, and callback, initializedCallback to let other plugin know there is update/the field is initialized window.plugin.sync.registerMapForSync = function(pluginName, fieldName, callback, initializedCallback)

And a function to let other plugin push their data to cloud(Realtime API documents) window.plugin.sync.updateMap = function(pluginName, fieldName, keyArray)

Each data of each plugin is handled by a RegisteredMap, it will create/open Realtime API documents, push/listen update to the document. Each data update is bundle with a lastUpdateUUID to let other client determine it's a local/remote update.

And there is a Authorizer to authorize with realtime api and run callback after auth

And finally a RegisteredPluginsFields to bridge between Authorizer and multiple RegisteredMap, it would initialize all RegisteredMap after Authorizer authroized, and check the Authorizer.isAuthed() periodically and initialize all non-initialized RegisteredMap

And yes I think I was working to get a "team sharing" function to it. For that there was a uuid generated for each client and a lastUpdateUUID store with data on each Realtime API Document. But other then that, there wasn't much "team sharing" function implemented.

For "team sharing" to work, I think it should create 2 set of Authorizer, RegisteredPluginsFields, 1 for personal account and 1 for team account. and add correspond registerMapForSync, updateMap for team data.