jmr wrote: > Shawn Walker wrote: >> Brock Pytlik wrote: >> >>> Here's the CR: >>> http://cr.opensolaris.org/~bpytlik/ips-bug-2989-v1/ >>> >>> and the bug: >>> http://defect.opensolaris.org/bz/show_bug.cgi?id=2989 >>> >>> The idea is that if indexing fails for any reason during install, >>> image-update, or uninstall, we attempt to reindex from scratch. This >>> will at least hide the KeyErrors and other issues from the users until >>> we can fix the root cause of those problems. >>> >> >> client.py: >> line 140: you added space to the end of the line here >> >> lines 575-586: As I understand the localization process, you can't >> take one localized and blindly append it to another localized string >> (mid-sentence, especially) and get a reliable result due to >> subject-verb-order, etc. I'd recommend either passing the full string >> for each case to _() or dynamically constructing the strong *first* >> before passing it to _() at line 586. >> >> I also wonder what impact this will have on the GUI, etc. Should the >> re-index logic you added to client.py be a shared method in one of the >> search modules that can be called by the GUI or client.py as needed >> instead of solely being in client.py? >> > That would certainly help us. We got hit with a stopper bug for BTS > because we hadn't picked up indexing code changes in duplicated code > and brought them into the GUI. Of course we really want to get rid of > the duplicated code asap so a shared Client API is the way to go for > both pkg(1) and IPS GUI. > > JR I'm going to be revving the search communication protocol shortly. Aiming for Build 99 if my memory is correct. Essentially, the idea is to send XML or XML-like (I don't really care about the exact markup language we choose) queries and responses.
Goals: 1) Extensible, should never need to rev the protocol again. 2) Flexible, allow the client to express many kinds of searches and allow the server to return additional information other than the action line 3) Safe, server should fail gracefully when unable to process the request and client should always be able to parse the response, possibly discarding information it doesn't know what to do with. Key features: 1) Tags will be distinguished from search tokens syntactically 2) Server and client (or front-end and back-end) have to be able to deal with tags they don't recognize. 3) Tags can be marked as optional, optional-ignore, or required (names still to be decided on). A tag marked required that the back-end doesn't recognize will result in the search failing. If the back-end doesn't recognize a tag marked optional, it will ignore the tag and search for the token using its default scheme. If the back-end doesn't recognize a tag marked optional-ignore it will ignore the search term. I'm not certain all three of these will be present. Required is clearly needed, and the default tag setting might be optional. I'm still working on a use case for optional-ignore. 4) Client can request a limited number of responses. It can also use a tag to choose a ranking method, if the back-end supports that. 5) The back end will return the text of entire actions. It's up to the front-end to decide how to display that information to the user. The hope is that by marking tags as optional or required, and separating tags and search tokens, we'll never have to rev the protocol again. As new features come into front and back-end they can be added asynchronously without terrible consequences or needing to rev the protocol. As an example (and this syntax is by no means fixed, it's just for demonstration purposes), the back-end might send to the front-end: <xml> <a list of requested options it couldn't support> <fmriname> <action text="..." _optional tags_> </fmriname> <fmriname> .... </fmriname> </xml> The client's format I'm less clear on. It could be something like this: <xml> <options> <sortby=score> <startreturn=20> <endreturn=30> </options> <request> <bool=and> <bool=or required=true> <token=openoffice field=description casesensitive=false> <token=/usr/bin field=dir cassensitive=true> </bool> <token="zfs list" phrase=true required=true> </request> Or we might try to encode all the information in a url string. It's something I need to look into more. Are there features the GUI needs which wouldn't fit into this framework? What other issues currently prevent the GUI from interfacing with the search back-end as currently constructed? Thanks, Brock >> Cheers, >> > > ------------------------------------------------------------------------ > > _______________________________________________ > pkg-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
