ScriptSpot and TAO

TAO Website
1

I’d like to welcome Chris Grant into our fold, at least temporarily but hopefully permanently. We’re currently discussing a way to integrate both SS and TAO’s Community Script Initiative.

I’ve made the CSI forum viewable to anyone who can see this forum. Things are still being worked out, but will be open for business on Friday. The Community Repository thread is here: http://tech-artists.org/forum/showthread.php?t=7

I’m moving the discussion about SS and TAO integration here so others can see and comment, especially Aryeh.

My slightly edited initial email to Chris:

We are about to launch the first part of a new community initiative, called Community Repositories. I am contacting you about further expansion and potential integration between scriptspot and these repositories.

What the Community Repositories aim to do is:
Create a common library of stable and flexible functions that TA’s can use, instead of having to write their own
Provide an easy way for TA’s to publish scripts and updates
Provide a simple way to work collaboratively on scripts

We have the community, and personnel, to make this happen- but trying to build traffic, recognition, and fame, is something ScriptSpot has already. If I felt SS was not the right venue for what I seek to do, I wouldn’t hesitate to do our own thing, but you are an active member of the community and SS’s technical chops are very up to par.

Basically, what I’d like to see is, users can ‘hook up’ their repositories for auto-publish at ScriptSpot. That way, the newest version would always be available for download. This would create a very good solution for the ‘marketability’ of the CR scripts, since as it stands, it would not be immediately clear for non-technical users how they can get the scripts. And having to manually publish via scriptspot has the opposite problem- it is something most script writers will probably not want to do, and use one or the other. It also provides a much larger audience for the scripts in addition to the built-in infrastructure.

What we can bring to scriptspot is an active and participating community, support for scripts, and potential for future development. I also pay a SA to develop custom software for us, so any of these modifications he can take care of (I have worked with him for years and he is an excellent SA). Imagine if someone had a problem with a script at SS, or would like to see an improvement (for example, I added a ‘connect and slide’ functionality to csPolyTool’s slide tool just this morning). They can flag the tool or post a request. Anyone willing can then make a new repository for the tool with the needed upgrades. The upgrades can be published as a ‘branch’ of the original tool (the author of the original can merge these changes onto the trunk). This would provide a real improvement to the static nature of SS and the still somewhat fractured community.

Eventually I’d like to incorporate new ideas and existing sites into a community infrastructure. Unique identity is very important so I don’t want to try to ‘absorb’ anyone or anything. I just want to work together and interface better.

Slightly edited response:

Rob - thanks for contacting me. I’ve been following your posts about the community scripting area at TAO for quite a while now as I’m quite intrigued by the idea. I think its definitely worth pursuing techniques for interoperability. I’d definitely like to see what you guys have developed for the version control system / community scripting area so expect a PM from me soon on TAO.

Presumably you’re just kicking around some ideas right now as far as integration possibilities go right? Do you have any specific ideas? I can’t think of any similar examples where 2 sites integrate content in this rather unique way. Off the top of my head here are some my thoughts as far as integration issues go:
[ol]
[li]Username sync between the 2 sites? Presumably at first it’d be manual - ie uses registers at TAO and at SS then admin grants additional rights of sorts… Come to think of it SS has openID support so if you and I enable openID broadcast users could regiser once then authenticate with the other site’s login. [/li]> [li]There is an XML-RPC api on SS that should allow for remote posts. However I’m not sure how that would handle remote updates to existing content… For example, pushing the first script shouldn’t be a problem but pushing version 1.1 might be… No reason its not doable just pointing out an area I’m unsure about the issues… [/li]> [li]Push or pull updates? Does SS pull updates from TAO or do you push them to SS? Presumably they’d just get pushed every time there was a code commit / fork on TAO[/li]> [/ol]

One of the things I love about integration possibilities is it’ll enable SS to support additional apps. I’ve been wanting to add Maya / XSI support for quite a while it just keeps falling on the back burner… If we are successfully able to integrate the 2 sites then SS support for Maya / XSI happens by default since TAO is platform agnostic…

Interesting possibilities that’s for sure, I look forward to talking with your about this further.

My response in the next post.

2

Username sync: I’ll defer to Aryeh.

Remote posting: It would probably be simplest to have a ‘static URL’ for the most recent version of a file (so basically just remove the bold part of [noparse]http://tech-artists.org/hg/robgalanakis/tao_function_library/file/[/noparse][B]5b2a0254b76a/[/B]fn_arrOps.ms). This would be the path published to SS and it would always pull down the newest version. We’d still need to coordinate to publish new posts.

Push/Pull: It would be nice for some info, such as the changelog, to be updated on the SS site. I am not against all redundancy- for example, it may just be easier to have a description typed up on SS instead of a ‘descr.txt’ in the repository that is auto-pushed to SS as the description for the script). Since the code would be hosted in the repository, all that would need to be updated at SS is the URL if we do not have static URL’s.

Actually this sort of ‘auto-population’ based on some keyword files in the repository can maybe fill out all fields… or they can just be manually entered.

Right now the questions are predominantly technical so Aryeh knows far more than I do. When design or creative things come up I’ll jump back in.

3

And one more thing about this all. I sort of mention it here: http://tech-artists.org/forum/showthread.php?t=238 It is a way for end-users to easily get plugins and scripts. In the long-term, I’d really like to find a way to integrate this idea into a 3D program so they could grab our compliant scripts, since it shouldn’t require anything drastic to change in our 3D apps like in my other posts.

4

So I think I will be starting work on the Max integration of these ideas relatively soon. It’ll be a jump-off point of sorts for some of the 3D software topics I’ve discussed, a type of proof of concept, or ideals rather than concepts.

In order to do this I really would like to get the ball rolling on what needs to be done on the web-side.

5

Hey Rob - sorry for the delay… Despite the current economic conditions I’m actually buried at work right now and just haven’t had the level of time to commit that I had hoped I would.

I’m actually still mulling over some of the technical issues. While this may seem like an easy thing to do for you - just put some code together that works with TAO, I’d like to do the code right the first time so its maintainable and generic enough that it could work in multiple scenarios…

6

[QUOTE=Rob Galanakis;2053]I’m moving the discussion about SS and TAO integration here so others can see and comment, especially Aryeh.[/quote]
I didn’t look before now, didn’t realize there was anything here I needed to look at.

Username sync between the 2 sites? Presumably at first it’d be manual - ie uses registers at TAO and at SS then admin grants additional rights of sorts… Come to think of it SS has openID support so if you and I enable openID broadcast users could regiser once then authenticate with the other site’s login.

I haven’t looked into OpenID support for vB before, but I’m fairly sure someone’s written a plugin. The thing to watch out for would be if it’s clumsy and poorly integrated: there’s no official OpenID (or other multiple-login) support in vBulletin. I could look at that, and potentially fix it up if necessary.

There is an XML-RPC api on SS that should allow for remote posts. However I’m not sure how that would handle remote updates to existing content… For example, pushing the first script shouldn’t be a problem but pushing version 1.1 might be… No reason its not doable just pointing out an area I’m unsure about the issues…

I’m probably missing some context here. I take it that ScriptSpot is a site where scripts are posted. If it uses custom software, I wouldn’t know anything about its capability to handle this kind of thing. I’m sure it could be written if desired.

Push or pull updates? Does SS pull updates from TAO or do you push them to SS? Presumably they’d just get pushed every time there was a code commit / fork on TAO

Either way should be relatively straightforward, there shouldn’t be a big practical difference. Push would be likely nicer because then updates are immediate.
[QUOTE=Rob Galanakis;2055]Remote posting: It would probably be simplest to have a ‘static URL’ for the most recent version of a file (so basically just remove the bold part of [noparse]http://tech-artists.org/hg/robgalanakis/tao_function_library/file/[/noparse][B]5b2a0254b76a/[/B]fn_arrOps.ms). This would be the path published to SS and it would always pull down the newest version. We’d still need to coordinate to publish new posts.[/quote]
As I noted in the other thread, you can just replace the revision ID with “tip” and you’ll get the latest one.
[QUOTE=Rob Galanakis;2055]Push/Pull: It would be nice for some info, such as the changelog, to be updated on the SS site. I am not against all redundancy- for example, it may just be easier to have a description typed up on SS instead of a ‘descr.txt’ in the repository that is auto-pushed to SS as the description for the script). Since the code would be hosted in the repository, all that would need to be updated at SS is the URL if we do not have static URL’s.

Actually this sort of ‘auto-population’ based on some keyword files in the repository can maybe fill out all fields… or they can just be manually entered.[/QUOTE]
I’m definitely missing too much context to comment intelligently here.

7

[QUOTE=Aryeh Gregor;2104]I didn’t look before now, didn’t realize there was anything here I needed to look at.
I’m probably missing some context here. I take it that ScriptSpot is a site where scripts are posted. If it uses custom software, I wouldn’t know anything about its capability to handle this kind of thing. I’m sure it could be written if desired.
[/QUOTE]

Aryeh - ScriptSpot is an end user focused portal primarily for maxscripts that has been around for over 8 years now. The great thing is that its incredibly prolific because of its age. Its community based, built on drupal (drupal.org) and allows users (script devs) to contribute their scripts.

What I’ve found is the system works great for low / mid level scripters but really high level devs that have a hundred scripts aren’t going to sit around and upload content all day long - let alone update em… Cue TAO - Rob and I have been talking about how ScriptSpot users get exposure to the latest and greatest from TAO thats fed into ScriptSpot automagically. From my perspective its an opportunity to bring some high level content to SS and provide TAO with greater community exposure.

8

I am starting work on a tool that will allow users to install and uninstall scripts from ScriptSpot/TAO with a click or two. I am not a web programmer and was thinking about how I am going to interface, and was thinking- couldn’t we use an intermediary format, such as XML, and use that to communicate? The XML could even be stored in the Repository, as markup data for the repository- SS would read this, and probably need its own markup data as well (what branches have been made, additional keywords, etc.), and this would obviously be auto-generated from SS. I’d be able to read this data and display it however I want, anyone with access to it would. And since we are using an intermediary to communicate, it makes it much easier to expand later on with other sites, since it modularizes and abstracts communication and exchange between components. Is this a good idea?

Also, Chris and Aryeh, can I move this discussion into the public CSI forum? I figure others may have good ideas- we can make another thread if there’s any sensitive technical information to discuss.

9

[QUOTE=Rob Galanakis;2148]I am starting work on a tool that will allow users to install and uninstall scripts from ScriptSpot/TAO with a click or two. I am not a web programmer and was thinking about how I am going to interface, and was thinking- couldn’t we use an intermediary format, such as XML, and use that to communicate? The XML could even be stored in the Repository, as markup data for the repository- SS would read this, and probably need its own markup data as well (what branches have been made, additional keywords, etc.), and this would obviously be auto-generated from SS. I’d be able to read this data and display it however I want, anyone with access to it would. And since we are using an intermediary to communicate, it makes it much easier to expand later on with other sites, since it modularizes and abstracts communication and exchange between components. Is this a good idea?[/quote]
As long as we’re sure we’re going to stick with Mercurial and not move to some other versioning system, it would make the most sense to just use Mercurial for transfer of the actual data, either directly or through its web interface. If we want to transfer some extra info, like a list of repositories, a simple one-URL-per-line format is likely to be easier to work with than XML.

I would have to have a more detailed specification of what kind of functionality is wanted exactly before I could say more on how we’d want to implement it. Design decisions need to come before implementation decisions, not after.
[QUOTE=Rob Galanakis;2148]Also, Chris and Aryeh, can I move this discussion into the public CSI forum? I figure others may have good ideas- we can make another thread if there’s any sensitive technical information to discuss.[/QUOTE]
Go ahead.

10

[QUOTE=Aryeh Gregor;2149]As long as we’re sure we’re going to stick with Mercurial and not move to some other versioning system, it would make the most sense to just use Mercurial for transfer of the actual data, either directly or through its web interface. If we want to transfer some extra info, like a list of repositories, a simple one-URL-per-line format is likely to be easier to work with than XML.[/quote]

Can you explain some more about this?

I would have to have a more detailed specification of what kind of functionality is wanted exactly before I could say more on how we’d want to implement it. Design decisions need to come before implementation decisions, not after.

Well that’s the thing… I am not sure of the nitty-gritty specs. I can give a more broad vision and what I think we’ll need, but I am not the most qualified person to be making these design decisions. All I can say for sure is that we can’t really know anything for sure. The system has to be built for extensibility and exchange of information- what information I am not exactly sure and that information will change, even if I did know exactly what it was right now- that can be said for sure. Which is why I suggested some sort of intermediary data format, like XML. I’d like to be able to communicate with a Wordpress blog, or Snipplr, for example, but odds are these projects will all be implemented by different people, and the simpler and more straightforward, the less proprietary, what they have the do, the faster it will be for them and the more likely it will get done.

But realizing that specific info will still help, what I’d like is, take something like this as an example:
http://scriptspot.com/3ds-max/screenedge-ui
Or even better, create a ScriptSpot account and go to submit a script. Basically, all those fields could be put into XML which SS can know how to parse. This could be generated per-repository by TAO, or even made by hand, or another site, or another utility on this site (like, it could be done via Mercurial/during check in of other files, or checked out and edited by hand and checked back in), I don’t know. Similarly, someone with a Wordpress should be able to make a new page on their site, and with some new module or tool, propogate that tool like a ScriptSpot page using what data is in an XML file. The same way, my tool for 3ds Max can read these XML files and display them however I want. This way, all the sites communicate via the same meta-data, which is always up to date, but can use it in whatever way they want.

I’m not set on using a certain type or exchange, I just use XML as an example as I’m mildly familiar with it.

11

I really need more details on what’s wanted here.

That’s kind of disheartening.

I have to know what kind of information will need to be transmitted before I can say what data format would be best.

[quote=Rob Galanakis;2150]But realizing that specific info will still help, what I’d like is, take something like this as an example:
http://scriptspot.com/3ds-max/screenedge-ui[/quote]
What part of it is an example . . . ?

I’ll do that.

Communicate what? If you want a protocol for communicating arbitrary data, you can just use HTTP or whatever. You can’t just say “we need to communicate stuff”. Communicating stuff in the abstract sense is a solved problem. The question is what you want to communicate.

What you presumably want is for one site to be able to achieve some specific action on another site remotely, such as “we want things uploaded to TAO repositories to automatically appear as files on SS under such-and-such conditions”. That I can do (with cooperation from SS). I can’t do “let different sites communicate meta-data to each other”. Or rather I don’t have to do any work to allow that, it’s already possible using established technologies. What to communicate and what that should do is what you need to tell me.

12

So I discussed some more with Sim, here is a summary of the discussion:

In Python terms, I make a module, I want to share. I want SS to list it, and stay updated. I also want to interface it on my wordpress blog, because I need the attention and because I don’t like how SS looks or lists the information. I also have this tool I’m working on, that allows users to download and install modules from inside Max in real time, but I need a unique way of displaying information. And SS is about to go through a major overhaul and replace all of its code. We need a way to have the same set of data represented in a multitude of ways that is independent from each other. Hyperlinks aren’t acceptable because of the formal and interface issues, I need to have control over presentation and organization.

There lives along with the script, or somewhere else, a metadata file (we’ll use XML for an example, but it can be any sort of markup language TBD). This metadata file can be updated when the user checks in to the repo, or when they edit their SS description, or from their blog, or whatever- and the other sources now use the most recent metadata (in the case of the repo, it’d have to be synced to first).

Sim says: What you’re talking about, I guess, is making up a whole protocol by which a third party can say something like “get a list of projects at this URL”, “get further info about this particular project”, and “download the latest copy of this project”. Then implementing servers for that protocol at TAO and SS.

For now, Sim is going to work on the repos, adding in the needed functionality. In a few weeks, I’d like to have the exchange system worked out and specced out, so Sim can work on the TAO-side of things, Chris can work on the SS aspect, I can work on the Max side, and we can find someone to work on the Wordpress side. As long as how we are communicating is standardized and worked out, what we do on our own shouldn’t matter.

I’ll try and post what I think needs to be speced out later and others can give thoughts.

Edit: Moved into CSI forum.

13

Welcome to our website to purchase your favorite variety of fake designer handbags ,replica louis vuitton handbags , designer replica handbags , replica handbags ,and replica designer handbags.

14

YES! I would name your blog the dreamland!http://tech-artists.org/forum/showthread.php?t=7

15

Your information is really interesting and useful for me .I have learned many thing to read it .
Hope I will learn more to my stay here .