No announcement yet.

Script Library Database?

  • Filter
  • Time
  • Show
Clear All
new posts

    Script Library Database?

    Trying to find scripts on the script library is pretty tough. I was thinking about making a searchable database for them. It would mean more work for the script writers, but easier access and usability for end users. I would have to get permission from Richard first of course, but would like to see if there is any interest before I go any further.


    This is the fourth attempt at a script library, I was hoping this version would at least last a little while before someone decided to replace it.

    What would this new database do that the webboard's search engine can't?

    Nucleus Home Automation | System Specs
    News, support, and updates for Rover, Network Monitor, TimeIcons, and more


      Well, for starters, have them categorized by type or anything.
      Better search capabilities.
      List the most popular, hot etc.
      Possibly vote on them.

      Just random thoughts.


        I think it would be good if there was a script database. Something like Macromedia runs for Cold Fusion developers to share custom tags.

        Jeff Farmer

        Jeff Farmer
        HS 3, HSPhone
        My HS3 Plugins: CFHSExtras, Random, Restart, Tracker, WeatherXML, PanaBluRay
        Other Plugins In Use: APCUPSD, BLOnkyo, Device History, EasyTrigger, HSTouch Server, PHLocation2, Pushover, RFXCom, UltraGCIR3, UltraMon3, UltraPioneerAVR3, X10, Z-Wave

        Hardware: GoControl Irrigation Controler, Schlage Lever Lock, Schlage Deadbolt, Way2Call Hi-Phone, RFXCom RFXrec433 Receiver, WGL 800, TI-103, Z-Net, Pioneer 1120, Pioneer 1021, Pioneer LX302, Panasonic BDT-110, Panasonic BDT-210 x2


          It will be done in CF, but I won't host the scripts tho. Unless Richard wants to pay me [img]/infopop/emoticons/icon_wink.gif[/img]
          I was just going to link back here for them.


            <BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Originally posted by
            Well, for starters, have them categorized by type or anything.<HR></BLOCKQUOTE>

            We have that. (By type, at least; without knowing what kind of "anything" you have in mind, I don't know if we have them. That's kinda the point -- what don't we already have that we need, and how come we didn't notice ourselves needing it all this time?)

            <BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Better search capabilities.<HR></BLOCKQUOTE>

            I believe that was the question -- in what way? What search could it do that I can't do now?

            <BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Possibly vote on them.<HR></BLOCKQUOTE>

            We have that.

            <BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>List the most popular, hot etc.<HR></BLOCKQUOTE>

            That's one thing we can't do now. (I'm not sure what the difference is between popular and hot, so it's possible it's two things we can't do now.) I just don't see why anyone would want it. Who comes to the script library thinking "I want the most popular script" instead of "I want a script that does so-and-so"?

            Changing systems is going to cause a lot of hassle, so it has to provide enough improvements to justify that hassle. So far, I am not seeing any non-trivial improvements at all. Maybe someone else who can see these advantages can explain it better?

            Nucleus Home Automation | System Specs
            News, support, and updates for Rover, Network Monitor, TimeIcons, and more


              A forum is not a place for a script library, but you did what you could do with what you have. To try and browse through the scripts trying to read titles that may or may not make sense, ppl posting msgs where they shouldn't, it's just seems, to me anyway, that it is just not organized very well.
              I was just offering my services and nothing on this end would have to change, but in the end, it's your decision.


                I think a CF based Script Library similar to the CF Exchange would be a great idea. Esp. if authors took the time to keep their info updated with current version info and etc. Successive releases could be automatically linked to the original as well as related info and required other parts.

                Yes, some of these are possible inside of a forum via links but it's not quite the same. There are other improvements that would come as a result of having the listings in a db.

                I think you should do it and let everyone decide for themselves. I'd be happy to help with the CF if needed or if another hosting location is needed. We're using CF MX with SQL Server 2000. If your setup is similar we could set up a db replication and have a redundant copy online in no time. Of course with MX having the ability to publish the script data via SOAP/XML is a given which isn't possible with a forum either.

                I hate trying to track down script info in a forum format and am tired of searching for this and that all of the time. Searches should be a last resort for finding stuff when all else fails and a well designed UI that is intuitive will significantly reduce the dependancy on searches. Searches also consume many more resources server side.

                Don't misinterpret this as me stating that searches as evil, I am merely trying to make the point that searches should not be used as THE primary navigational metaphor.


                  I'm not familiar with the technology, but in general I find databases very useful and they are enablers for capabilities that were not obvious at the outset.


                    I guess it's up to Rich in the end. I don't know if Rich is going to want to have a reason to do it before doing it. Probably not, since it sounds like I'm the only one who likes having it happen in that order. Hope it works out for y'all.

                    Nucleus Home Automation | System Specs
                    News, support, and updates for Rover, Network Monitor, TimeIcons, and more


                      I think this is a great idea. I'm not convinced that CF is the right solution though. Having used InfoPoop searches I find that it leaves much to be desired IMHO. I'd propose something more inline with or as an architecture (but without the commercialism you have to put up with).

                      In the old days you could browse all scripts using the ftp directory at the HS website but now that is not available even though sometimes it would be nice if you have an idea what you're looking for.

                      Overall, the Script library and script archive are too monolithic. There's no interactive way to organize (sort) the messages interactively. For that matter, it would be neat to be able to sort messages in all catagories and threads in the same way.





                        I think that having a better organized script library is a good idea but building something that won't be supported won't solve anything. I can pretty much tell you that unless the HomeSeer web server supports Cold Fusion, this won't get off the ground. I can pretty much guess that it doesn't since I've worked with Rich on getting SSI functioning on the Apache server.

                        In addition, the ideal script library system is the HomeSeer Updater. This is where ALL scripts and plug-ins should be released. How much more convenient could it be? It has easy install for new users and will eventually (I believe) have an uninstall feature. By far the biggest advantage of using the Updater is that it knows when something is new to you.

                        If the script library is difficult to navigate, having a web-based database-driven system will not improve that. Proper subject lines and script description in the forum messages are needed. If an author doesn't do it here they won't do it in the newly proposed system either. You can add all the bells and whistles you want but the system's success is in the accuracy of the data and not necessarily the feature set.

                        Additionally, there really aren't very many individuals that release their scripts if you think about it. If you are going to make it harder to publish author's scripts, they just won't publish them.

                        Based on a few assumptions, write it in Perl with no database and it could quickly be implemented. It also needs to be self-maintaining and secure.

                        Just my two cents!

                        // AJ

                        My Links: Website | HomeSeer Status | System Description


                          Did someone say Perl?! [img]/infopop/emoticons/icon_smile.gif[/img]




                            If you think the ideal library is the best place to release scripts, you and I are on different planets. No, make that universes!

                            The very last place I'd want to look in the updater. I would much rather keep scripts where they are today, if there were no other choice. The updater is not for browsing and causal interactions.

                            To me, the only value in the updater is for HomeSeer updates. I don't really enjoy using it and I dont see any benefit in it being my only source for scripts. Not at all.

                            I'm sorry, I completely disagree with you on this point.



                              I think the updater would be the best place if it included a few new features. The ability to do keyword searches (script authors could put keywords in their scripts' install.txt file), categorization, and a reworked UI to support "library" type usage. Take it a step farther and add the ability to publish your scripts using the updater application itself!

                              The more I think about it, the more sense it makes - it's really a combination of the database idea with the built-in installation and version control features of the updater.

                              In fact, I would be willing to chip in some development time to help put that together if Rich is interested in making the updater more robust for this kind of usage.