The list of existing modules to be included in collection

[devolonter]

Let's make a list of existing modules that we can include in the collection.

[devolonter]

XML - https://github.com/skn3/monkeymodules/tree/master/skn3/xml
JSON - http://code.google.com/p/monkey-json/

[frameland]

I have a pretty well tested css class,
Would that be needed or is css to exotic?

[devolonter]

It would be great to have css class in collection, I think. So, I vote for it.

[swoolcock]

As I mentioned on the Monkey forums, the Diddy XML parser is available too (minus dependencies). You can take the Base64 stuff from Diddy too if you want.

[devolonter]

@swoolcock Thanks for suggestion! XML module from @skn3 suits us very well. Moreover, Jonathan is a part of our team and he will support it by himself.

As for Base64, thank you for permission! We'd love to include it in the collection.

[swoolcock]

When I offered the Base64 stuff I was kinda hinting that I wanted to join the team. :)

[devolonter]

Excellent! I’ve added you to the team, now you can create repositories and push them. Welcome! :)

P.S. I am sorry for late and rare answers. I'm a little busy right now. This weekend I will prepare some wiki documents about development and structure of the collection so that we can discuss it. And I think we will start to work next week.

[therevills]

With the XML parser you will should test all that is available for speed, functionality and reliability. Also it may pay to look into using native commands to parse the XML.

[swoolcock]

As soon as we extern the XML, we lose control over its platform independence. We'd need some really good unit tests.

[therevills]

True, but if we had the standard functions defined in Monkey and extern them to the native code the speed would be near perfect. If need be you could add "fixes" around the code based on the differences...

And really isnt this what Monkey/Mojo current classes/function do themselves at the end of the day...

[skn3]

I think one of the rules for this pub collection should be that everything is monkeycode, or at least will work on all future platforms without requiring new code.

It's definitely a lot more tedious work to wrap cross target native stuff into a common interface. Best to keep things in monkeycode so it will be compatible with all future targets. A good example would be the blitzmax target; if we switched to native libs we would have to find a solution for that. Brucey's Libxml could be used but your then complicating the requirements and over complicating the nature of pub.

There is no reason we can't optimise important things over time?.

[therevills]

If everything is going to be Monkey code, then it really limits what modules you are going to do... it all depends on your objectives.

[skn3]

Myn is just one opinion, so not the final word. I just pictured the pub repo being for core functionality that people can use in all of their projects on any target.

Maybe monkeycode only is a bit ambitious? I guess we need to decide if pub should support all targets?

[swoolcock]

Really, I think we should aim for 99% pure Monkey code. Any externs
should be in their own submodule, clearly marked as such. Maybe
something like pub.native?
Anything that's not supported by a particular target should either have
a stub method, or wrapped with:

#If TARGET=(supported target) ...
' code
#Else
#Error "Unsupported on this target."
#End

[devolonter]

I mentioned native code in wiki. I think this is a reasonable approach

[therevills]

Sounds good to me :)

Actually I really like the idea of trying to use MonkeyCode if the native code doesnt exist... might use that for Diddy ;)

[skn3]

There is a good example here: (wrapper.monkey) http://code.google.com/p/chartboost-monkey/ monkeycode emulation for the chartboost functionality.

[frameland]

Tweening module: http://www.monkeycoder.co.nz/Community/posts.php?topic=4173
No dependencies on mojo