Hi Henrik,
I think we mostly agree. Our concept of the JSON library we created each is different, as you already said.
<quote>
You may dislike this, saying that your JSON utility generates is JSON
as an entity, but in modern
programming JSON isn't just an island it's may just be a part of the greater
scheme involving generation of
code to a complex UI framework.
</quoute>
IMO packaging a service program separately and using it in a larger framework can go hand in hand as we see in OpenRPGUI. That is one thing the IBM i community hasn't really grasped yet and the situation we are all in really emphasizes that: We need to have programs/service programs as building blocks of our applications. Small modules which can be reused in many situations. A module is just like a puzzle piece of our application(s). And may very well fit in many puzzles we create. And it is not just about having those modules somewhere, we need an easy way for the whole process: download, installation/update, documentation, integration, ... . One command must be enough, like: install powerext-core
If you installed powerext core you can reuse your JSON service program. Ok. But what if someone only needs JSON support in his application. Or you need to fix something only in your JSON service progam, then what about packaging, distributing, updating ... documentation. Perhaps you don't have a need for this as long as you "only" work in your powerext environment. And it is not just about your own environment. Any fix should be available to everyone else. In most cases you don't know who is using your framework.
Some of this you already answered but I just wanted to point it out for everyone else.
Good luck with your project in Sweden.
Best Regards
Mihael
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Henrik Rützou
Sent: Tuesday, April 05, 2011 8:27 PM
To: RPG programming on the IBM i / System i
Subject: Re: RPG, open source, and the web
Mihael,
ad1. I do partly agree - the number of IBM I Open Source projects is rather
small, and there are overlaps,
however the number of IBM I servers installed is also rather small compared
with MS and Linux - but is that
an excuse not to collaborate?
ad2. Your JSON utility and subprocedures are based on an OO thinking
approach, mine is based on a Procedural
thinking approach, you have a lot of subprocedues to solve what I basically
solves in two. I dont say the one
method is better than the other - I just say the methodology is different.
There is however also a "catch" here, since both XML, HTML and JSON shares
the same hierarchical data
structure - so my two subprocedures jsonNode and jsonEndNode (no there is no
prefix, there is however an suffix)
can easely be replaced by their "sisters" xmlNode/xmlEndNode and
htmlNode/htmlEndNode sharing the same
approach - and by the way be very usefull and easy to use if you creates
program generators that creates code
(as an example CRUD services) in SQLRPGLE that is a procedural language.
I do however agree - it is NOT fine grained - it dosn't offer one solution
to one problem, it offers a set of solutions
to common programming task related to WEB2 programming not covered by
CGIDEV2 and still it shares
CGIDEV2 I/O buffers so you can use either my API's subprocedures or CGIDEV2
procedures or you can
mixed them in the same program while your JSON utility is more as to speak
limited to solve only one
specific task - generating JSON.
I do insert JSON code as just a part of the javascript generated in the
output buffer - JSON code that is
generated in the middle of at total page generated as a mix of different
CGIDEV2 based predefined templates
in any client language , this is where the "data" JSON object is just an
insertion in the output buffer of a
standarized lower level program called by the main API the generates UI
code:
,resizable:true
,store:new Ext.data.SimpleStore({
fields:["XALNGC","select"]
,data:[
["da","da - Danish"]
,["de","de - German"]
,["en","en - English (US)"]
,["en_GB","en_GB - English (UK)"]
,["es","es - Spanish"]
,["fr","fr - French"]
,["it","it - Italian"]
,["nl","nl - Dutch"]
,["pt","pt - Portugese"]
]
})
,mode:"local"
,editable:true
,forceSelection:true
,hiddenName:"XALNGC"
There is no programming involved in this in high level - or rather there is
a generic service that can insert
the "data" array in the output buffer when requested - but this service
works as standard in the same output
buffer that any other program that generates output - and the JSON service
API just becomes a tool in a
much larger framework.
This is program/API collaboration and that is why programs also needs a
common ground to be working
under. You may dislike this, saying that your JSON utility generates is JSON
as an entity, but in modern
programming JSON isn't just an island it's may just be a part of the greater
scheme involving generation of
code to a complex UI framework.
My API docs can be better - I agree, but just developing the total
framework, doing "proof of concept projects"
and starting the first IBM I cloud based service with a partner, as an one
man show in only two years, has
been a chalange.
"It started with a kiss" - no it started with a two month analysis and a
blue print without a single statement
being written, and in the same time discussing coding paradigms with LEAN
educated psycologists to gain
coding efficiency, 6 month coding the basic API's without as much as a
"Hello world" on the screen other
than for testing purposes.
Mihael, you may think I'm crazy bringing in LEAN psycologist into
programming, but just notise the "commas"
that is set in the front instead of the back in the above code - the human
brain processes these commas in a
rate 3 times faster than if it was in the end of the statement if the code
is hirachical structured - in 10 statements
you cannot hardly measure the diffence - but programmers during years has to
read million of statements and suddenly
the time to mindmapping to code makes a difference.
Again, here is an example to bring people into Open Source/Mind Sharing in
practise - I haven't used a single
$ on that project - but a lot of time.
On Mon, Apr 4, 2011 at 8:13 AM, Schmidt, Mihael
<Mihael.Schmidt@xxxxxxxxxxx>wrote:
Hi,
<quote>
What I am referring to is the lack of collaboration between various Open
Source projects on IBM I and also the lack of collaboration between smaller
ISV's in general.
</quote>
I don't think that there is more lack of collaboration in the IBM i open
source community than in any other community. This open source community is
just evolving. You will see the same lack everywhere else. It is just that
this community is so small it really stands out when there is a lack of
collab.
In Java there are half a dozen log frameworks and dozens of web frameworks.
Where is the collaboration there?
<quote>
When I see how my Core API is meet (my core API just extends CGIDEV2 with
about 80-90 new subprocedures that may overlap even your XMLi) in the IBM I
community nobody of the "Kings of other projects" even bother to download
and try it - because "Think" if there were some areas where it worked
smarter, better or faster. So it is safer to write "I don't know it"
signaling - "I don't bother at all".
</quote>
You should not be so full of yourself.
And just if some persons/groups have (open source) software which works in
the same space doesn't mean that they have to work together. They may have
reasons for not doing so.
Open Source is also about freedom.
And for example I got a JSON library and you got your powerext
library/framework which also handles JSON I would not use yours for several
reasons. Some are: API style (every data type has to be added as a string,
lack of constants (at least in your docs/examples), static holding of data
internally, procedure naming/no prefix), API docs, packaging (not fine
grained enough for me).
My 2 cents.
Mihael
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
midrange.com
