Closed GoogleCodeExporter closed 9 years ago
GoogleCodeExporter
commented
9 years ago see
http://code.google.com/p/csipsimple/issues/detail?id=410#c1
http://code.google.com/p/csipsimple/issues/detail?id=586#c1
http://code.google.com/p/csipsimple/issues/detail?id=871#c1Original comment by r3gis...@gmail.com on 16 Nov 2013 at 10:50
GoogleCodeExporter
commented
9 years ago So thius has been merged into a duplicate that has been merged into a duplicate
that has been merged into a wont fix. I.e. no intend to give any solution a
chance either directly in csipsimple either bey plugin of llma/tasker.
Sad to hear that. Will have to lookout for an alternative :(Original comment by gaston.g...@web.de on 16 Nov 2013 at 11:33
GoogleCodeExporter
commented
9 years ago If you read my comments on links given, you'll understand that the solution is
to address this need with a plugin. It's a Wont Fix *IN THIS ISSUE LIST*!!!
I would like to add that I develop CSipSimple on my free time (nights, weekends
and holidays). I released it just in case it could benefit anybody else. There
is no company behind CSipSimple and that's why you can't expect a pro support
for it and instead it's expected users take time to learn by themselves. And
that's also why there is absolutely no problem if you find an alternative that
match better your needs. I can only advise you to look first at opensource/free
as in speech alternatives such as Linphone, SipDroid and ImsDroid.
However, couple of points as you don't want to read more the links given above :
The app it's released under free/libre license anyone can contribute to it and
the app has an API that allows third party apps to control sip accounts state.
BTW, that's what was already done by some skilled users (a plugin for
csipsimple for tasker exists). (https://github.com/luklanis/csipsimple-plugin/)
I've a project that I also develop on my free time (and I've few..) to propose
an opensource/free alternative to tasker/locale. This project will obviously
include a plugin for csipsimple that will address most of needs listed in links
above. But it will be a *different* project. It's not yet release because it
takes time to finalize to avoid to get a lot of feedback from users. It also
takes time because supporting csispimple and replying to everybody like I'm
currently doing with you takes time and while this is done no code is produced !
So :
- do not be sad
- take control over software instead of being controlled by software. To do so, search and try to understand things by yourself. Learning leads to Knowledge, Knowledge to freedom !
Original comment by r3gis...@gmail.com on 16 Nov 2013 at 2:26
GoogleCodeExporter
commented
9 years ago
> So :
> - do not be sad
> - take control over software instead of being controlled by software. To do
so,
> search and try to understand things by yourself. Learning leads to Knowledge,
> Knowledge to freedom !
Only because you develop for free and you don't get my Point is no reason to
get personel. For sure my knowledge should not be your concern since you don't
even know me. And if you would know me your concern would surly be eben less ;-)
Another poinr: I did read all the comments and not only the ones pointed to. I
am not against a plugin solution in general. The Problem with plugins like this
one is with th eredundancy they may introduce. Imagine I use tasker and your
solution would use llma this requires me the redundant use of both apps which
adds complexity and thus Problem potential as well as bettery load.
The proposed plugin solution using tasker is a 3rd grade plugin solution where
each grade Expresses the software complexity which in turn increases the
probklem potential. The "3rd" comes from 3 APIs required to get the "required"
function, and represent the minimal complexity of the solution (best case),
wheras the worst case would go upt to 7th grade. In this precise case 6th grade
may be more realistic which is still huge.
In some situations even this complexity is no Problem when it is surpasses or
neared by the direct implementation complexity (grade 0). If for instance you
would Need to implement tasker like complexity into csipsimple to achieve the
goal.
So far for the academic in me getting the theoretical analysis point.
Now to the app control me or me it thing:
Having had a look into all the app Options I guessed that you were at least
using the NetworkInfo structure to check th econnection states to be able to
determine which Connection type is active and deciding wheter to Register or
not. So my thought was that implementing the code for checking the WifiInfo
structure in Addition to get the SSID would be very straight Forward (without
having looked into the code) with near 0 complexity and much more future proven
than any plugin solution.
While I know a bit of Android, I did never develop for it. But I did consider
having a look into th ecsipsimple code, but the "Won't fix" Status of the
request refrained me from doing so as there seems to be no interest in getting
zthis into the app itself.
So if the "won't fix" is not th efinal word I may have a look and eventually
contribute the code as time permits.
Original comment by gaston.g...@web.de on 18 Nov 2013 at 10:19
GoogleCodeExporter
commented
9 years ago """
Only because you develop for free and you don't get my Point is no reason to
get personel. For sure my knowledge should not be your concern since you don't
even know me. And if you would know me your concern would surly be eben less ;-)
"""
Sorry if I was rude. I'm just really tired providing support instead of
development. I repeat things hundred times and people does not take time to
read and search by themselves. That was my point. Try to search and read by
yourself first.
"""
Imagine I use tasker and your solution would use llma
"""
That's not true. A plugin can be compatible with llama, tasker and locale. A
single plugin.
"""
Problem potential as well as bettery load.
"""
That's not true, these apps are designed to use as less battery as possible
only being notified when conditions changes. Besides they factorize the
treatment of these events which makes actually less battery consumption than if
all apps register all android events.
"""
The "3rd" comes from 3 APIs required to get the "required" function
"""
This already exists in csipsimple and there is a stable API to control sip
accounts/features.
"""
If for instance you would Need to implement tasker like complexity into
csipsimple to achieve the goal.
"""
It's far to be simple to be done cleanly and to address all possible ideas.
Your idea is only one that is requested. (It's indeed the one the most
requested, but it's not the only one). Reimplementing something already
implemented cleanly (a pluggable way) somewhere else is always loss of time and
bad idea.
"""
Addition to get the SSID would be very straight Forward (without having looked
into the code) with near 0 complexity and much more future proven than any
plugin solution.
"""
You are absolutely right. Technically speaking would be very very simple to add
only SSID. However, you do not take into account very important point :
- User experience.
Many users has no technical background and are afraid by too many settings.
Introducing even more things for 5% users is maybe not a good idea. Keeping
things simple is better. Simple and focused. Do one thing and do it well.
That's what I try to do with csipsimple. That's why there is a stable 3rd party
API usable for other app that would like to focus on secondary features (other
than pure SIP).
From your comment you are an engineer. The pure engineer approach is good, but
when applied to user experience it become a nightmare for users.
On this point, Apple approach changed things on the good way. 'There's an app
for that' and each of their app is simple. They've done things to far for me as
their approach results in restricting capabilities of software they distribute.
I believe in the fact there is a way between the Apple way and the engineer
way. This way implies each app focus on its topic, that they have a first level
of configuration that is easy to use by user, and a second level of
configuration for geek/expert. These apps should also be focused on one topic
and provide a 3rd party api stable and documented to allow other apps focused
on other topics to work with these apps.
To give you an idea, I even resent having contacts list inside csipsimple.
Apparently this is part of very expected scope of a SIP app; but that is not
obvious.
The approach having one app for each thing and app working together is really
the one of Android. The entire android system software design is made to permit
that, and internally use that. There is a phone app, a contact app, a internal
telephony app.
Each app provide a SDK extending the core SDK. Apps doing same thing implement
the same sdk (see the openintent project).
It produces apps independant, focused and leave users free to choose the best
app for one topic.
"""
While I know a bit of Android, I did never develop for it. But I did consider
having a look into th ecsipsimple code, but the "Won't fix" Status of the
request refrained me from doing so as there seems to be no interest in getting
zthis into the app itself.
"""
It's definitely a won't fix *inside* csipsimple. But definitely not a won't fix
somewhere else. It is just a request that is not relevant of CSipSimple project
as I strongly believe in the fact such feature should take place in a different
apps focused on context aware settings. This will allow much more things :
being aware of your GPS location, of your google calendar, of what the weather
looks like outside... whatever you can imagine is possible in this case. And it
will not become and endless run implementing all ideas of all users inside a
*SIP* application.
Instead, a context aware application is *made* to address this topic. So why
re-inventing the wheel inside csipsimple? Why introducing more settings in the
app that most users will not understand? Why not trying to do something that
could be reused by other SIP app : linphone, sipdroid, imsdroid... if we
succeed in doing some common interface between all open apps, only one plugin
will be able to address all sip apps, leaving users free to choose their sip
app and their context aware app.
Original comment by r3gis...@gmail.com on 18 Nov 2013 at 10:55
GoogleCodeExporter
commented
9 years ago
"""
That's not true. A plugin can be compatible with llama, tasker and locale. A
single plugin.
"""
That was an example only
"""
That's not true, these apps are designed to use as less battery as possible
only being notified when conditions changes. Besides they factorize the
treatment of these events which makes actually less battery consumption than if
all apps register all android events.
""""
Designed for battery saving or not, does not matter. The more apps the more
battery load.
"""
This already exists in csipsimple and there is a stable API to control sip
accounts/features.
"""
Ok, you doid not get the point. This is about application complexity and about
API usage complexity in particular. This is not my lecture room so I won't go
any deeperr into this. The complexity I stated is fact and has nothing to do
with the existance of an API but the complexity generated by its use
independent of th eAPI complexity itself.
"""
Addition to get the SSID would be very straight Forward (without having looked
into the code) with near 0 complexity and much more future proven than any
plugin solution.
"""
"""
You are absolutely right. Technically speaking would be very very simple to add
only SSID. However, you do not take into account very important point :
- User experience.
"""
I do take many more things into consideration as what I write ;-) ! The
"complex option" argument has a long beard and is just sign of bad design as I
would tell my students ;-) The easisets way (not the only, and not always the
best) is to pack the options inexperienced users would not use into an "expert"
mode. Argument gone. In most cases this allows to hide away already existing
options as well, cleaning up the overall interface for inexperienced users
making it even more straight forward for them.
"""
The approach having one app for each thing and app working together is really
the one of Android. The entire android system software design is made to permit
that, and internally use that. There is a phone app, a contact app, a internal
telephony app.
Each app provide a SDK extending the core SDK. Apps doing same thing implement
the same sdk (see the openintent project).
It produces apps independant, focused and leave users free to choose the best
app for one topic.
"""
Using a feature just because it is available and commonly used is not always a
decision of good design.
"""
It's definitely a won't fix *inside* csipsimple.
"""
Np, I'll lookout for an alternative.
"""
It is just a request that is not relevant of CSipSimple project as I strongly
believe in the fact such feature should take place in a different apps focused
on context aware settings.
This will allow much more things : being aware of your GPS location, of your
google calendar, of what the weather looks like outside... whatever you can
imagine is possible in this case. And it will not become and endless run
implementing all ideas of all users inside a *SIP* application.
Instead, a context aware application is *made* to address this topic. So why
re-inventing the wheel inside csipsimple? Why introducing more settings in the
app that most users will not understand? Why not trying to do something that
could be reused by other SIP app : linphone, sipdroid, imsdroid... if we
succeed in doing some common interface between all open apps, only one plugin
will be able to address all sip apps, leaving users free to choose their sip
app and their context aware app.
"""
This is a different kettle of fish being about context compexity and
information relation. I agree with you that more complex rules like GPS and
calendars are out of scope of csipsimple. But ethe WLAN optin is already
buildin making it a relate information and SSID being part of it does not add
much additional complexity. So for me SSID filtering still belongs into
csipsimple. Am option with an condition is not really reinventing the wheel,
neither.
If we follow the separate what is separatable logic csipsimple would be
separated into a keypad app, a sip app, an rtp ap, codec aps, audio output app,
audio input app,... each of theam being separatable again,...
Also if an external application is to be used (for GPS for instance),
csipsimple should be the plugin by itself not requiring any plugin in between.
This reduces application adn usage complexity a lot being less erro prone.
Unfortunately I will have to move on. But regardless of that, thanks for this
great app. Will keep it until I find my alternative.
Original comment by gaston.g...@web.de on 19 Nov 2013 at 10:25
GoogleCodeExporter
commented
9 years ago @gaston : thanks a lot for the time you spent exposing your vision. Always
enriching to have different points of view.
There is very interesting points you raise. However I think the big point is
that you try to apply very academic/theorical approach to a system that works
at much higher abstraction level than what you consider.
For example, the definition itself of an application on android is probably
something that at your working level you would call more "module" or
"component".
And using this definition, your
"""
If we follow the separate what is separatable logic csipsimple would be
separated into a keypad app, a sip app, an rtp ap, codec aps, audio output app,
audio input app,... each of theam being separatable again,...
"""
Is something absolute true and it's the case there is a module for each thing
you describe. Everything related to sip currently uses pjsip stack that is
totally modular. CSipSimple has a UI part that can be separated from the rest.
It's the UI module (and in android a module is an application). CSipSimple has
a service module that is what I call the API and that can be controlled by UI
modules bundled with the app but also by any other apps with correct rights.
The service module hold the glue with the pjsip implementation. And pjsip
itself is separated into a lot of modules that have each a clean API. That's
what made successful and easy the intergration of pjsip in Asterisk server to
provide ICE feature first and what made asterisk developer choose pjsip for the
next version of their server. That's also how all big software piece with a
correct design works internally. For example, if you have a look to chrome
browser code, you'll find a lot of component in it. Each separable from each
other. That's what make possible to have in csipsimple the webrtc echo
canceller and webrtc codecs. That's what make android os allowed to use webrtc
echo canceller too.
These projects are complex compounded projects, and separating things into
cleanly separated modules is very sane approach. It's the same for csipsimple.
It's already internally separated into UI and service and it allows any other
module to use this service. In android a module can be an app.
On very small apps doing just pure algorithm or implementing a single RFC, your
points are very valid I think and it's good approach to keep things as simple
as possible. However you can not apply that to all systems. The only rules that
are good sense rule and applies to all informatics stuff I did is the :
http://www.python.org/dev/peps/pep-0020/
That's the only thing that I always take into account (and that's why I love
python ;) ). Other points should always be thought again when in front of a new
system.
BTW you'll notice one point in the previous:
*Complex is better than complicated.*
So for me it's better to have a complex api usage in the middle than a
complicated inline (by inline I mean integrated to the core app) code inside
what manages pure connectivity. This because the complicated code inline will
grow with users needs and requests as this topic definition is not yet final.
It's not a RFC topic here, it's a topic to give a not fully defined feature to
user. The feature to decide when *account* should be enabled. (It's different
from when sip can use a connectivity/interface which is a different topic for
me).
This feature should be addressed a (maybe several) focused way. And the current
way I propose (and that is already partially implemented with the locale
plugin), is to use a third party app dedicated to condition detection and set
of settings accordingly. CSipSimple already have this working. It works and has
no bug. If I introduce the code you propose, it's a risk to introduce bug for
everybody. If done outside, it's less error prone for everybody as csipsimple
will just continue working. And this feature development life-cycle can be
managed outside. I don't care if the complexity rate of that based on an
academic measure is higher. It's less complicated and easier to manage :
- for dev: as anyone can implement this feature the way they prefer and enhance this feature with whatever subfeature they want.
- for users : as they only take this plugin if they need it and pick the plugin that gives them what they expect without needing upgrade of their core sip app.
Also :
In the face of ambiguity, refuse the temptation to guess.
When you guess :
"""
The more apps the more battery load.
"""
You guess it works this way on android. On some system your assumption is
totally true. On Android you are mistaken. If you really start to learn and
understand the internal of android you'll understand what consume battery and
how what they call "apps" are loaded. Mobile OS system manages the cpu and
multitasking a very different way than destkop apps. Apps are launched
dynamically based on manifest of the apps (telling when it should be notified
etc).
So if you have 10 apps registering for GPS and tracking GPS location, you'll
consume way more battery than if you have only 1 app that track gps cleverly
and inform the 10 others apps only when necessary. It will consume less cpu
cycle and will consume less RAM. So 11 apps is better than 10 apps for your
battery. (GPS is just an example it goes exactly the same if you want to check
something periodically etc).
Also on android, apps even if marked 'running' does not necessarily consume cpu
cycle. An app can be frozen in ram and consume 0 battery. Also apps !=
processes. Apps are just about bundling several component. And these components
in android sdk are activities (ui), broadcast receivers (something that
register some kind of hub) and services (something that is really a process
running in background).
When you install csipsimple codecs plugin there is absolutely 0 battery
overhead from these apps. Better, the process of these plugins apps does
nothing even if the plugin is used.
So, again, the feature is important, understand and maybe I'll personnally do
that. But it's not something that goes inside CSipSimple issue list. Maybe we
can open an issue list somewhere else for plugins. But there will be no code
commit inside csipsimple repository about that, and thus no issue list about
that in csipsimple.
There will be a different project for the plugin somewhere else, maybe done by
me, maybe done by other.
Academic approach is very important and very interesting to have as background.
However, I think that you and your students should also have a look to real big
projects and how these works, especially opensource projects. The best way to
learn a system is to read good opensource code and understand it. I'm not
saying csipsimple is internally a good code to read. I'm talking about OSes
source code, about browser source code etc. The way I currently know android is
that I've read their source code (also contributed to it), I've also
intensively read the source code of the dalvik jvm.
Even reading books you'll always miss important parts of systems. Books are
good to have a first overview and have a background, but when you start to
enter the internals, nothing will be as good as reading real source code of
those knowing system internals. And each system/language is different and have
different approach and you usually have to adapt these approach instead of
trying to apply academic rules on these systems. That's why I'm very quick to
ask anyone searching by themselves and learning by themselves, and why I
quickly get very frustrated when you replied without trying to understand the
problematic.
Original comment by r3gis...@gmail.com on 20 Nov 2013 at 11:26
GoogleCodeExporter
commented
9 years ago In the face of ambiguity, refuse the temptation to guess.
When you guess :
"""
The more apps the more battery load.
"""
Sorry, but this gets much to personal again. Your Point-of view is always the
same, you know it all and yout Counter part has not the required knowledge.
Also, there is no "akademic Point of view", just how stuff works and has been
analyzed to work.
So you can assume that I never guess, so th ebattery Topic above was not
guessed but exactely works likje that in th escope of what I was stating.
Movinbg the scope, be it only a bit, just for a Counter Argument to work is
just distorting th ediscussion to non-sense.
Also when asking others not to guess you should absolutely avoid to do so in
first place. Whatever told you I was never part of a large Project (and I
really assume that you don't believe that csipsimple is such a big project) or
that I don't know how opensource works it must be guessing as you are
completely wrong.
Worthless to go on. This said, csipsimple has gone from my phone now.
/colsed
Original comment by gaston.g...@web.de on 27 Nov 2013 at 1:34
Original issue reported on code.google.com by
gaston.g...@web.deon 16 Nov 2013 at 12:19