Chris,
Am 09.08.2012 um 06:00 schrieb Chris Morley:
..
> While a lot of the details are over my head the ideas your talking about are
> important.
> We are not so good at long time planning in linuxcnc but it has seemed to
> work up to this point never-the-less.
>
> I see a few things coming in the nearish future that may put us in a position
> of considering developing
> a new version.
> licensing is a bit of a mess right now - which limits who will use/develop
> use if there is legal questions of use/distribution.
> GTK3 is going to be a requirement especially if we want to stay current with
> GLADE.
> I see that pygtk is not going to be developed further, pyobject is the new
> direction.
> There is interest in deeper changes in linuxcnc, but I think it is quite
> impenetrable, Michael being the real driving force
> for new features, basically I think because he has spent the time to
> understand it the best (and is interested).
>
> May be at the point that a lot of code needs to be updated for the new
> libraries (which I realize doesn't need to happen
> right away) we might want to consider a rewrite to fix our licensing
> inconsistencies and limitations of current structure.
>
> By writing a new version there are no pressure to get it done right away, the
> current version could continue.
>
> I am wondering if its a case of 'start to build it and they will come' - to
> help develop it :)
> I guess the first thing to do is list what the goals are to see if it is
> worth the trouble to get there.
>
> Enjoying the discussion...
> Chris M
linking a rewrite of LinuxCNC ("LinuxCNC3") and a licensing cleanup is an
interesting idea, and I think worth exploring in more detail.
I dont have a suggestion for a future license yet, but assume we had one (lets
call it v3license) and it would enable bringing in other key components more
easily.
I need to think this through, but my first take on a greenfield approach to V3
would be:
1. carrying forward HAL and RTAPI, all the HAL components, motion, comp, the
sim/rt environment to v3license would be key.
2. dropping NML/RCS completely and replacing it with zeromq and a
protobuf-based messaging and language bindings will be a huge relief
(eventually - post learning curve, but it will). It's just messaging, RPC, and
an error queue, plus serialisation - thats all, and these themes are well
covered.
3. HAL needs a bit of a brushup to be tied into the new messaging, but that
should be forward compatible.
4. interpreter: I'd say the current *structure* had its day (NB: I dont mean
cradek's work) and it would be fair to reconsider whether C++ is actually
needed or one could go to, say, a Python-based interpreter to start with; if
C++ were the decision, I would consider Joseph Coffland's OpenSCAM interpreter
code as an alternative to port to.
5. It would be a great point to start work on the revamped structure
(interpreter more closely tied into motion) I discussed with Chris. For that,
cutting loose from the existing NLM framework would actually be a benefit.
Probably a block-based interface would be better than carrying forward canon as
a public API.
6. task: given a proper messaging API binding I see no good reason to retain
C++ here, replacing by Python is fine IMO
7. GUI's: porting forward GladeVCP to GTK3 and pyGobject would be clearly a
milestone. I love Axis, but I dont quite see how it can realistically be
forward-ported.
8. Language and toolkit plethora: I'd suggest to not carry forward
TCL/Tk/TkInter use.
9. emcsh, emcrsh, halrmt & friends: happy to let these go and replace by a
Python API to start with - they'd be heavily affected by 2) and no point in
keeping C++ for that.
10. It would be the opportunity to slide in Redis as a persistent key/value
store (not just tool table, for istance machine state - parameters - too,
probably config)
11. The coding creep towards a 'single PC does it all' model should be
revisited - I dont like it at all.
---
1) is the dealbreaker IMO - redoing the HAL, RTAPI, component infrastructure
basically for license purposes is out of reach IMO. Is that doable?
Assume this can be achieved, a first great milestone would be to have the
brushed-up gladevcp run a HAL-only application; maybe low-level talk to motion
through a revamped API (Python). Actually I think LinuxCNC kindof 'misses a
market' - I see use for HAL-only applications with GUI.
Then, go from there filling in parts - messaging infrastructure, task,
interpreter.
whale of a plan.. this will years of coexistence of v2 and v3. But I agree it
is time to consider that cut.
- Michael
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
